[cfe-dev] Implementing P1099R5 (using enum) in clang

[Shachaf Co via cfe-dev]

Thank you very much!

I'll start looking into the UsingShadowDecls.
Are there some resources for learning about it, except for clang's
documentation and the code itself?
I find the documentation quite lacking, and there are many internal
concepts to understand such as Contexts, Scopes, the whole name lookup
process etc.

Shachaf

On Fri, Jul 10, 2020 at 7:48 PM Richard Smith <richard at metafoo.co.uk> wrote:

> On Fri, 10 Jul 2020, 08:39 David Rector via cfe-dev, <
> cfe-dev at lists.llvm.org> wrote:
>
>> You definitely want to represent the original declaration in the AST —
>> never just expand it right away into the underlying semantics.
>>
>
> +1
>
> Others know the AST much better than I do, but: I think you could *also*
>> implement the easy way as well, by adding implicit UsingShadowDecls for
>> each enumerator, each linked to the original UsingEnumDecl.
>>
>
> This is the approach that I would attempt -- model UsingEnumDecl similarly
> to UsingDecl.
>
> Or better yet, somehow add a single shadow decl that is a transparent
>> lookup context, somehow.
>>
>
> It's tempting to try to build a representation whose size is independent
> of the number of enumerators, but this is likely to present problems --
> name lookup for an injected enumerator name would find a declaration with a
> different name, which is going to confuse some parts of clang. Also, all
> name lookups would presumably need to additionally look for the shadow
> decl, much as we do for "using namespace". We need to pay an O(n) cost to
> check that the enumerators don't conflict with other declarations in their
> scope anyway, so building an O(n) representation seems likely to be OK.
>
> I believe UsingShadowDecls are introduced by UsingDecls to handle whenever
>> multiple individual declarations need to be introduced into a context —
>> someone correct me if I’m wrong.  There is definitely precedent for
>> introducing implicit declarations simply for lookup purposes, e.g.
>> VarTemplateDecl instantiations get added to a DeclContext.  It’s annoying
>> to deal with but since it’s already being done, I see no reason not to
>> introducing UsingShadowDecls to handle the implementation in this way.
>>
>> - Dave
>>
>> On Jul 10, 2020, at 7:01 AM, Shachaf Co via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> I'm new to Clang, and decided that I want to implement a small C++20
>> feature - the "using enum" proposal (
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html).
>>
>> The first part of the proposal, supporting syntax such as "using
>> Color::RED" is easy enough to implement, and basically requires removing an
>> if-statement and adding some diagnostics.
>>
>> However, I struggle finding the correct way to implement the "using enum
>> Color" syntax. There are two approaches that I see when trying to implement
>> it.
>>
>> The first approach is "expanding" it to a list of using-declarations (i.e
>> "using enum Color" would be equivalent to "using Color::RED, Color::BLUE,
>> ...). This approach is easier to implement, however the resulting AST won't
>> be as accurate.
>>
>> The second approach is creating a new AST node representing a
>> "UsingEnumDecl". This will generate a more "correct" AST, however it is
>> much more complicated to implement - it is more similar to using directives
>> ("using namespace ns"), whose implementation is complicated and heavily
>> affects the name lookup.
>>
>> What do you think is the correct way to implement the feature? Is
>> reducing the complexity worth degrading the accuracy of the AST?
>>
>> Thanks,
>> Shachaf
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200710/37ef41bb/attachment-0001.html>