Hi Andre and Harald,
It looks good to me too.
Indeed, the associate construct is a strange one since TKR guessing is done
at a very early stage so that the associate block can be parsed. About a
year ago, I started looking at tackling this by delaying parsing the blocks
until the containing block had been parsed and resolved. It nearly worked
and I think that I should get out my notes and restart :-)
In the meantime, this is more than band-aid, it is a necessary correction,
given the way associate is parsed.
Regards and thanks for the patch
Paul
On Tue, 18 Mar 2025 at 22:08, Harald Anlauf <anl...@gmx.de> wrote:
> Hi Andre,
>
> Am 17.03.25 um 09:56 schrieb Andre Vehreschild:
> > The issue is that the tbp (the typebound proc info structure) is not
> resolved
> > completely when the associate tries to do an early resolve to determine
> the
> > rank of the associate variable. When the expression to be resolved for
> that
> > contains a compcall, the resolve branches into the incorrect case and
> emits the
> > error. My current fix is to wait with generating the error message until
> the
> > type has been resolved completely (aka. symbol's resolve_symbol_called
> is set).
> > I am not sure, if this is correct, therefore CC'ing Paul, who, to my
> > knowledge, has more experience in the associate area. But everyone
> please feel
> > free to step in!
>
> your solution looks basically correct to me, but I wonder why to
> return early w/o error. Would the following logic be wrong?
>
> @@ -7349,7 +7357,8 @@ resolve_compcall (gfc_expr* e, const char **name)
> gfc_symtree* target;
>
> /* Check that's really a FUNCTION. */
> - if (!e->value.compcall.tbp->function)
> + if (!e->value.compcall.tbp->function
> + && e->symtree && e->symtree->n.sym->resolve_symbol_called)
> {
> gfc_error ("%qs at %L should be a FUNCTION",
> e->value.compcall.name, &e->where);
>
> Sorry if this is a stupid question. And not regtested, although
> it also fixes the original report.
>
> > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> If neither Paul steps in nor anybody else, go ahead and commit.
> Even if your patch were a band-aid, it does not look wrong, and
> if it is later found to be it can be improved...
>
> Thanks,
> Harald
>
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
