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