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

[Jacek Caban]

On 04.02.2021 13:00, Rémi Bernon wrote:
> On 2/4/21 12:48 PM, Jacek Caban wrote:
>> 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
>>
>
> Well there are examples in Wine IDLs where casts are used, like for 
> instance in oleidl.idl, when initializing constants.
>
> MIDL supports the following code for instance, which would be harder 
> to parse without help from the lexer:
>
>   []
>   interface ITest
>   {
>       typedef int T1;
>       const int V1 = 0x00000001;
>       const int V2 = (V1)+0x00000001;
>       const int V3 = (T1)+0x00000001;
>   }


Oh, right. So getting rid of lookup_namespace would be more problematic 
than I expected. Still, I think we can make it nicer. I will send 
comments to the original patch.


Jacek