Re: [PATCH] PR152531 inferred-type ASSOCIATE name giving spurious, "Expected argument list"

Hi Jerry,

It looks OK to me, except for one minor omission:

+! "Invalid association target" because:......?

OK for mainline and for backporting.

NOTE TO SELF: I must revive the attempt at two pass parsing.

Thanks for the patch.

Paul

On Fri, 5 Jun 2026 at 20:28, Jerry D <[email protected]> wrote:
>
> See attached patch.
>
> This one is also fairly straight forward.
>
> Regression tested on x86_64.
>
> OK for mainline and then backport to 16?
>
> Regards,
>
> Jerry
>
> ---
>
> In gfc_match_varspec, when parsing component references on an
> inferred-type ASSOCIATE name, the parser incorrectly matched the
> component name as a type-bound procedure .
>
> For inferred-type ASSOCIATE names the parse-time candidate type may
> differ from the final resolved type.  If gfc_find_component fails with the
> default access check, retry with noaccess=true; the resolution pass
> will substitute the correct type.
>
> Assisted by: Claude Sonnet 4.6
>
>         PR fortran/125531
>
> gcc/fortran/ChangeLog:
>
>         * primary.cc (gfc_match_varspec): Before erroring on a zero-argument
>         COMPCALL, check for a same-named data component and fall back to the
>         data-component path.  For inferred-type ASSOCIATE names, retry
>         gfc_find_component with noaccess=true when the normal search fails.
>
> gcc/testsuite/ChangeLog:
>
>         * gfortran.dg/associate_infer_program_type.f90: New test.
> ---