[lambda] Extract lambda functions from semantics.c.

On Jul 12, 2013, at 11:18 PM, Adam Butcher <adam@jessamine.co.uk> wrote:
> 	* gcc/cp/semantics.c (build_lambda_expr),
> 	(build_lambda_object), (begin_lambda_type), (lambda_return_type),
> 	(lambda_function), (lambda_capture_field_type), (is_capture_proxy),
> 	(is_normal_capture_proxy), (insert_capture_proxy),
> 	(insert_pending_capture_proxies), (lambda_proxy_type),
> 	(build_capture_proxy), (vla_capture_type),
> 	(register_capture_members), (add_default_capture),
> 	(lambda_expr_this_capture), (maybe_resolve_dummy),
> 	(nonlambda_method_basetype), (maybe_add_lambda_conv_op) and
> 	(is_lambda_ignored_entity): Moved definitions into ...
> 	* gcc/cp/lambda.c: ... this new file.


This can cause an incremental build failure because there are no dependencies:


When tree codes are added or moved, the check is then against the wrong number, and this will kill the build.

I'm still looking forward to the day when all the dependancies are unceremoniously ripped out, until then...

Ok?

On 04.09.2013 03:41, Gabriel Dos Reis wrote:
> On Tue, Sep 3, 2013 at 9:33 PM, Mike Stump <mikestump@comcast.net> 
> wrote:
>> On Jul 12, 2013, at 11:18 PM, Adam Butcher <adam@jessamine.co.uk> 
>> wrote:
>>>       * gcc/cp/semantics.c (build_lambda_expr),
>>>       (build_lambda_object), (begin_lambda_type), 
>>> (lambda_return_type),
>>>       (lambda_function), (lambda_capture_field_type), 
>>> (is_capture_proxy),
>>>       (is_normal_capture_proxy), (insert_capture_proxy),
>>>       (insert_pending_capture_proxies), (lambda_proxy_type),
>>>       (build_capture_proxy), (vla_capture_type),
>>>       (register_capture_members), (add_default_capture),
>>>       (lambda_expr_this_capture), (maybe_resolve_dummy),
>>>       (nonlambda_method_basetype), (maybe_add_lambda_conv_op) and
>>>       (is_lambda_ignored_entity): Moved definitions into ...
>>>       * gcc/cp/lambda.c: ... this new file.
>>
>>
>> This can cause an incremental build failure because there are no 
>> dependencies:
>>
>> diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
>> index 2c1774f..65dfe08 100644
>> --- a/gcc/cp/Make-lang.in
>> +++ b/gcc/cp/Make-lang.in
>> @@ -351,6 +351,7 @@ cp/vtable-class-hierarchy.o: 
>> cp/vtable-class-hierarchy.c \
>>  cp/name-lookup.o: cp/name-lookup.c $(CONFIG_H) $(SYSTEM_H) 
>> coretypes.h \
>>         $(TM_H) $(CXX_TREE_H) $(TIMEVAR_H) gt-cp-name-lookup.h 
>> $(PARAMS_H) \
>>         $(DIAGNOSTIC_CORE_H) $(FLAGS_H) debug.h pointer-set.h
>> +cp/lambda.o: cp/lambda.c $(CXX_TREE_H) $(CGRAPH_H) $(VEC_H) 
>> $(SYSTEM_H) coretypes.h
>>
>>  cp/cxx-pretty-print.o: cp/cxx-pretty-print.c $(CXX_PRETTY_PRINT_H) 
>> \
>>    $(CONFIG_H) $(SYSTEM_H) $(TM_H) coretypes.h $(CXX_TREE_H) 
>> tree-pretty-print.h
>>
>> When tree codes are added or moved, the check is then against the 
>> wrong number, and this will kill the build.
>>
>> I'm still looking forward to the day when all the dependancies are 
>> unceremoniously ripped out, until then...
>>
>> Ok?
>
> OK.
>
Eek.  I didn't realize dependencies had to be manually specified.  
That's prompted me to update a more recent patchset I'm working on where 
I've introduced a new header.

Is anyone working on using some use, perhaps filtered, of -MD (or -MDD) 
to generate deps on the fly?  I haven't looked into the GCC makefile 
system in any detail but I assume dependency handling is more complex 
than the standard usage pattern for -MD or I guess someone would have 
done it already.  Or are maintainers worried that auto deps will slow 
the build down too much?  In our team's experience with using -MD the 
overhead is negligible; especially when weighed up against the effort 
required to manually maintain deps.  It just takes make a little longer 
to start actually building anything.

On 04.09.2013 20:39, Gabriel Dos Reis wrote:
> On Wed, Sep 4, 2013 at 12:55 PM, Adam Butcher <adam@jessamine.co.uk> 
> wrote:
>
>> Is anyone working on using some use, perhaps filtered, of -MD (or 
>> -MDD) to
>> generate deps on the fly?
>
> See Tom's patch series.
>
Ah, yes.  Cool.  I guess it's just waiting on approval for each part; I 
note that a few front ends have already been OK'd.