Proposed patch to 13249

[Tobias Schlüter]

Victor Leikehman wrote:
> I suspected something like this, really :-)  Still, the existing
> code hacks around these problems in cases like the following:
> 
>   PROGRAM MAIN
>   INTEGER FOO
>   COMMON /FOO/ BAR
>   END
> 
> I just can't explain to myself why it is possible to work around
> this example, but not the one with module usage.
> 

I guess that's due to the way symbols are added to namespaces, but I 
don't understand that code all too well. I think the correct fix for 
this would be to not add the names of commons to namespaces at all but 
keep them separate. They are a different kind of names, and should be 
treated as such. I don't know if tentative parsing comes into the way 
here (I believe it doesn't, but I went through a tentative parse with 
gdb yesterday and the route it took was quite surprising), so that we 
would get problems similar to the ones in PR13575, related to the common 
name, if we did this.

WRT tentative parsing I'm trying to work out a scheme where only symbols 
in matched expressions would be added to namespaces. I.e. some kind of 
stack of new symbols, where symbols generated in unsuccessful matches 
are popped off once we have a MATCH_FAILURE, and added to the current 
namespace, once the whole expression has been matched. I don't know if 
that would be feasible. Especially the interaction with symbols which 
are already in the namespace from previous successful matches or which 
have been added in previous parts of the tentatively parsed expression 
seems mind-boggling.

I also don't understand too well what g95 does to circumvent this 
problem, the symbol handling code is involved in both codebases, and 
sometimes subtl different.

One possibility would be a complete port of expression matching from 
g95, I don't think gfortran has much changed WRT this since the fork. Of 
course, doing this would still require understanding this code.

> For full appreciation of the problem, I am missing an example of
> invalid code that is rejected now, but will be accepted if we
> remove the call to check_used as proposed.  If nothing else,
> we can use that example as a part of the test suite, especially
> for regression testing when a real fix to the problem will appear.

I thought Paul had given an example, mut maybe I misread.

- Tobi