[PATCH 2/5] widl: Support using qualified names for interfaces.

[Jacek Caban]

On 04.02.2021 11:52, Rémi Bernon wrote:
> On 2/3/21 4:30 PM, Rémi Bernon wrote:
>> On 2/3/21 4:22 PM, Jacek Caban wrote:
>>> On 02.02.2021 09:22, Rémi Bernon wrote:
>>>> And make qualified name lookup more robust:
>>>>
>>>> * Either parse a non-qualified name directly from
>>>>    the current (or global) namespace, or start
>>>>    parsing a qualified name.
>>>>
>>>> * Qualified name parsing uses the lookup namespace
>>>>    stack only to find types or sub-namespaces.
>>>
>>>
>>> I think it's a step in the right direction, but things like 
>>> find_qualified_type_or_error() resetting lookup_namespace as a side 
>>> effect does not look appealing.
>>>
>>>
>>> I wonder if we could entirely get rid of global lookup_namespace 
>>> variable. As far as parser is considered, namespace_pfx could just 
>>> return a namespace type that we could use to find types. That leaves 
>>> us with is_type() and is_namespace(), which are used in lexer. I'd 
>>> say that it's not a job of lexer to distinguish between an 
>>> identifier and a known type. Maybe we could just get rid of 
>>> aNAMESPACE and aKNOWNTYPE and deal with that in parser instead?
>>>
>>>
>>> Thanks,
>>>
>>> Jacek
>>>
>>
>> It may be better with a bit of refactoring but I was wary of changing 
>> existing logic too much, especially as this is WinRT only, so I just 
>> tried to build upon what was already there (with the lookup_namespace 
>> introduction earlier, and this change now).
>>
>> I could have a better look I guess.
>
> So I can probably clean this up a bit and get rid of the 
> lookup_namespace mechanism, but I think the lexer interaction trick is 
> going to be much more difficult to replace.
>
> For instance, the aIDENTIFIER / aKNOWNTYPE tokens help making 
> expressions parsing unambiguous. Consider the following expression:
>
>   '(' aIDENTIFIER ')' '&' aIDENTIFIER
>
> I think it's hard (if not impossible, but I'm definitely no bison 
> expert) to write a rule that can decide to parse it as a CAST 
> ADDRESSOF expression, or as an AND expression depending on whether the 
> identifiers are known types or not.
>
> Note that the CAST expression rule also needs to specify an operator 
> precedence modifier, which I don't know how to make dependent on the 
> rule actions.
>
> Also, there's the same conflicts happening in WinRT between qualified 
> type names and member accesses.
>
> From what I understand from bison documentation, there's a GLR mode 
> that can be used to solve this kind of situation, but I'm not sure if 
> it's the right or only solution.


If we need to support that then yes, it would be problematic. But should 
we support that at all? Unless I'm missing something, widl does not have 
a reason to understand cast expressions. Does midl have some concept of 
casts?


Jacek