| #
bc4d50f0 |
| 21-Jun-2024 |
Vlad Serebrennikov <serebrennikov.vladislav@gmail.com> |
[clang] Implement CWG2877 "Type-only lookup for using-enum-declarator" (#95399)
This patch implements 2024-05-31 resolution of a tentatively ready issue
[CWG2877](https://cplusplus.github.io/CWG/is
[clang] Implement CWG2877 "Type-only lookup for using-enum-declarator" (#95399)
This patch implements 2024-05-31 resolution of a tentatively ready issue
[CWG2877](https://cplusplus.github.io/CWG/issues/2877.html) "Type-only
lookup for using-enum-declarator", which supersedes earlier
[CWG2621](https://cplusplus.github.io/CWG/issues/2621.html) "Kind of
lookup for `using enum` declarations".
Now we perform type-only lookup (not to be confused with type-only
context) for `elaborated-enum-declarator`. This is the same kind of
lookup that elaborated type specifiers and base specifiers undergo.
I also found out (and fixed) that one of our existing tests claimed that
a dependent type can be used in `elaborated-enum-declarator`, but that's
not the case:
> The
[using-enum-declarator](http://eel.is/c++draft/enum.udecl#nt:using-enum-declarator)
shall designate a non-dependent type with a reachable
[enum-specifier](http://eel.is/c++draft/dcl.enum#nt:enum-specifier)[.](http://eel.is/c++draft/enum.udecl#1.sentence-2)
show more ...
|
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3 |
|
| #
b0c6fc81 |
| 07-Feb-2024 |
Timm Bäder <tbaeder@redhat.com> |
[clang][Interp] Ignore UsingEnumDecls
We previously aborted compilation when seeing one of them. Ignore
them instead, they have no effect on the generated bytecode.
|
|
Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
| #
54be300f |
| 29-Nov-2022 |
Shafik Yaghmour <shafik.yaghmour@intel.com> |
[Clang] Fix Sema::ClassifyName so that it classifies EnumConstantDecl as NonType when they are brought into scope via using enum
Currently Sema::ClassifyName(...) in some cases when an enumerator is
[Clang] Fix Sema::ClassifyName so that it classifies EnumConstantDecl as NonType when they are brought into scope via using enum
Currently Sema::ClassifyName(...) in some cases when an enumerator is brought
into scope via using enum during lookup it can end up being classified as an
OverloadSet. It looks like this was never accounted for when using enum support
was implemented and we need to add a check to allow an EnumConstantDecl to be
classified as NonType even when it is a class member.
This fixes:
https://github.com/llvm/llvm-project/issues/58057
https://github.com/llvm/llvm-project/issues/59014
https://github.com/llvm/llvm-project/issues/54746
Differential Revision: https://reviews.llvm.org/D138091
show more ...
|
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1 |
|
| #
3d208068 |
| 14-Sep-2022 |
Nathan Sidwell <nathan@acm.org> |
[clang][DR2621] using enum NAME lookup fix
Although using-enum's grammar is 'using elaborated-enum-specifier',
the lookup for the enum is ordinary lookup (and not the tagged-type
lookup that normall
[clang][DR2621] using enum NAME lookup fix
Although using-enum's grammar is 'using elaborated-enum-specifier',
the lookup for the enum is ordinary lookup (and not the tagged-type
lookup that normally occurs wth an tagged-type specifier). Thus (a)
we can find typedefs and (b) do not find enum tags hidden by a non-tag
name (the struct stat thing).
This reimplements that part of using-enum handling, to address DR2621,
where clang's behaviour does not match std intent (and other
compilers).
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D134283
show more ...
|
|
Revision tags: llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
b2d0c16e |
| 05-May-2021 |
Nathan Sidwell <nathan@acm.org> |
[clang] p1099 using enum part 2
This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is th
[clang] p1099 using enum part 2
This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is the boilerplate needed to get the
new class set up.
There is one case where we accept ill-formed, but I believe this is
merely an extended case of an existing bug, so consider it
orthogonal. AFAICT in class-scope the c++20 rule is that no 2 using
decls can bring in the same target decl ([namespace.udecl]/8). But we
already accept:
struct A { enum { a }; };
struct B : A { using A::a; };
struct C : B { using A::a;
using B::a; }; // same enumerator
this patch permits mixtures of 'using enum Bob;' and 'using Bob::member;' in the same way.
Differential Revision: https://reviews.llvm.org/D102241
show more ...
|