Guinevere Larsen <guinevere@redhat.com> writes:

This commit implements the missing support for [[N]]::'file.c'::var
syntax that was skipped on the previous commit.

This is done by adding a new value to the global parser_state, so that
the classify_name function can restrict its search for file names to the
specified linker namespace.  It had to be done this way because if the
logic was contained on the newly added "block: block COLONCOLON
FILENAME" rule, we would not have the name to rerun the search.
Did you consider adding the filename to the <whatever> type such that it
was available within the rule to allow for the filename to be re-looked
up?

I'd be interested to know if this was tried, why this was worse than
pushing parser state back to the lexer, which I always thought was not a
great design.

My one worry with this is, what if there is a file foo in the default namespace, and a function 'foo' in namespace 1

Could we misidentify this as being a filename, and then we rerun the search inside the "block: block COLONCOLON FILENAME" and find nothing, and raise an error when the expression was valid?

I'm not familiar enough with our parser to know if this is the case, but if it is and I understand it correctly, I think this is a possible failure case... Although if you think this is a failure that is too niche, I can go that route, mark it as such on the code and commit message, and remove the linker namespace ID from the parser.

-- 
Cheers,
Guinevere Larsen
It/she