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

[Rémi Bernon]

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.
-- 
Rémi Bernon <rbernon at codeweavers.com>