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

[Jacek Caban]

On 04.02.2021 13:45, Rémi Bernon wrote:
> On 2/4/21 1:35 PM, Jacek Caban wrote:
>> 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
>>
>
> I think getting rid of lookup_namespace is possible without too much 
> trouble, but with some prior refactoring, that I started here:
>
>
> https://github.com/rbernon/wine/compare/master...wip/widl-refactor/v1.patch 
>
>
> What will be hard is to fold the aKNOWNTYPE / aIDENTIFIER token.


Great, thanks. The new series seems good after a quick look.


Jacek