Re: [PATCH] PR152531 inferred-type ASSOCIATE name giving spurious, "Expected argument list"
Jerry D <[email protected]>
| Newsgroups | gmane.comp.gcc.patches,gmane.comp.gcc.fortran |
|---|---|
| Message-ID | <[email protected]> |
The master branch has been updated by Jerry DeLisle <[email protected]>: https://gcc.gnu.org/g:418c6b5fbab2b3bf5e7727657172864ae5440c1d commit r17-1394-g418c6b5fbab2b3bf5e7727657172864ae5440c1d Author: Jerry DeLisle <[email protected]> Date: Sat Jun 6 09:47:59 2026 -0700 On 6/5/26 11:20 PM, Paul Richard Thomas wrote: > 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. >> ---