[fpc-devel] Parsing procedural type and method directives

[Sven Barth]

Am 21.12.2021 um 21:37 schrieb Blaise--- via fpc-devel:
> 1) The following three routines:
>     pdecsub.pas!parse_parameter_dec
>     pdecvar.pas!maybe_parse_proc_directives
>     ptype.pas!read_named_type\procvar_dec
> create a dummy typesym for the procdef, for the sole purpose of 
> invoking parse_var_proc_directives, which merely extracts that 
> procdef. The attached parse_proctype_directives-1.patch replaces these 
> hacks with calls to the new routine parse_proctype_directives that 
> takes a procvardef directly.
>
>
> 2) Now, there remain three callers of the old parse_var_proc_directives:
>     pdecl.pas!consts_dec x2
>     pdecl.pas!types_dec
>     pgenutil.pas!generate_specialization_phase2
> and all of them have procvardefs readily available. The attached 
> parse_proctype_directives-2.patch drops parse_var_proc_directives in 
> favour of parse_proctype_directives.
>
> P.S. It seems that the cases localvarsym and paravarsym @ 
> parse_var_proc_directives were unreachable.
>
>
> 3) The attached consts_dec.patch refactors consts_dec:
>     skipequal -> skip_initialiser, with better locality;
>     deduplicates:
>         calls to check_proc_directive & parse_proctype_directives;
>         checks of current_settings;
>         indexations of current_asmdata.asmlists;
>     elucidates comments.
>
>
> 4) The attached pdflags.patch removes the line
>> pdflags:=pdflags+[pd_body,pd_implemen];
> from pgenutil.pas!generate_specialization_phase2. The variable pdflags 
> is not used after that statement; thus, it is confusing: makes the 
> code look like some related logic is missing.
>
>
> 5) The attached parse_objrec_proc_directives.patch changes 
> parse_object_proc_directives & parse_record_proc_directives to take 
> tprocdef instead of tabstractprocdef.

All accepted.

Regards,
Sven