Commit Graph

3464 Commits

Author SHA1 Message Date
Alexander Kornienko 637da9de4c Revert "[clang] template / auto deduction deduces common sugar"
This reverts commit d200db3863, which causes a
clang crash. See https://reviews.llvm.org/D111283#3785755

Test case for convenience:
```
template <typename T>
using P = int T::*;

template <typename T, typename... A>
void j(P<T>, T, A...);

template <typename T>
void j(P<T>, T);

struct S {
  int b;
};
void g(P<S> k, S s) { j(k, s); }
```
2022-09-13 12:18:07 +02:00
Chuanqi Xu 79fa0ec8c4 [C++20] [Modules] Make member functions with a in-class definition in HU implicitly inline
According to [dcl.inline]p7/note4,

> In the global module, a function defined within a class definition is
> implicitly inline.

And the declarations in the header unit are attached to the global
module fragment. So the function defined within a class definition in
header units should be implicitly inline too.

This fixes https://github.com/llvm/llvm-project/issues/57571.
2022-09-13 13:11:56 +08:00
Corentin Jabot 7eead180b9 [Clang] NFC: Make UnqualifiedId::Kind private for consistency.
Differential Revision: https://reviews.llvm.org/D133703
2022-09-12 19:14:06 +02:00
Jun Zhang 1d51bb824f
[Clang] Reword diagnostic for scope identifier with linkage
If the declaration of an identifier has block scope, and the identifier has
external or internal linkage, the declaration shall have no initializer for
the identifier.

Clang now gives a more suitable diagnosis for this case.
Fixes https://github.com/llvm/llvm-project/issues/57478

Signed-off-by: Jun Zhang <jun@junz.org>

 Differential Revision: https://reviews.llvm.org/D133088
2022-09-12 22:40:54 +08:00
Matheus Izvekov d200db3863
[clang] template / auto deduction deduces common sugar
After upgrading the type deduction machinery to retain type sugar in
D110216, we were left with a situation where there is no general
well behaved mechanism in Clang to unify the type sugar of multiple
deductions of the same type parameter.

So we ended up making an arbitrary choice: keep the sugar of the first
deduction, ignore subsequent ones.

In general, we already had this problem, but in a smaller scale.
The result of the conditional operator and many other binary ops
could benefit from such a mechanism.

This patch implements such a type sugar unification mechanism.

The basics:

This patch introduces a `getCommonSugaredType(QualType X, QualType Y)`
method to ASTContext which implements this functionality, and uses it
for unifying the results of type deduction and return type deduction.
This will return the most derived type sugar which occurs in both X and
Y.

Example:

Suppose we have these types:
```
using Animal = int;
using Cat = Animal;
using Dog = Animal;

using Tom = Cat;
using Spike = Dog;
using Tyke = Dog;
```
For `X = Tom, Y = Spike`, this will result in `Animal`.
For `X = Spike, Y = Tyke`, this will result in `Dog`.

How it works:

We take two types, X and Y, which we wish to unify as input.
These types must have the same (qualified or unqualified) canonical
type.

We dive down fast through top-level type sugar nodes, to the
underlying canonical node. If these canonical nodes differ, we
build a common one out of the two, unifying any sugar they had.
Note that this might involve a recursive call to unify any children
of those. We then return that canonical node, handling any qualifiers.

If they don't differ, we walk up the list of sugar type nodes we dived
through, finding the last identical pair, and returning that as the
result, again handling qualifiers.

Note that this patch will not unify sugar nodes if they are not
identical already. We will simply strip off top-level sugar nodes that
differ between X and Y. This sugar node unification will instead be
implemented in a subsequent patch.

This patch also implements a few users of this mechanism:
* Template argument deduction.
* Auto deduction, for functions returning auto / decltype(auto), with
  special handling for initializer_list as well.

Further users will be implemented in a subsequent patch.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D111283
2022-09-08 19:17:48 +02:00
Kazu Hirata b7a7aeee90 [clang] Qualify auto in range-based for loops (NFC) 2022-09-03 23:27:27 -07:00
Utkarsh Saxena 4a043c6376 PotentiallyEvaluatedContext in a ImmediateFunctionContext.
Body of `consteval` should be in an `ImmediateFunctionContext` instead of `ConstantEvaluated`.
PotentiallyEvaluated expressions in Immediate functions are in a `ImmediateFunctionContext` as well.

Fixes https://github.com/llvm/llvm-project/issues/51182
Original divergence: https://godbolt.org/z/vadGT5j6f

Differential Revision: https://reviews.llvm.org/D132659
2022-08-26 10:30:10 +02:00
Roy Jacobson b1c960fc6d [Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.

During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.

Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.

Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman

Differential Revision: https://reviews.llvm.org/D128619
2022-08-26 00:52:52 +03:00
Roy Jacobson 70770a16bc Revert "[Clang] Implement P0848 (Conditionally Trivial Special Member Functions)"
See bug report here: https://github.com/llvm/llvm-project/issues/57351
This reverts commit 7171615099.
2022-08-25 09:11:06 +03:00
Chris Bieneman bdf1327fea [HLSL] Entry functions require param annotation
HLSL entry function parameters must have parameter annotations. This
allows appropriate intrinsic values to be populated into parameters
during code generation.

This does not handle entry function return values, which will be
handled in a subsequent commit because we don't currently support any
annotations that are valid for function returns.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D131625
2022-08-24 14:35:11 -05:00
Roy Jacobson 7171615099 [Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.

During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.

Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.

Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman

Differential Revision: https://reviews.llvm.org/D128619
2022-08-23 21:48:42 +03:00
Christopher Di Bella e9ef45635b [clang] adds unary type transformations as compiler built-ins
Adds

* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`

These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.

[1]: http://wg21.link/meta.trans

Co-authored-by: zoecarver

Reviewed By: aaron.ballman, rsmith

Differential Revision: https://reviews.llvm.org/D116203
2022-08-22 03:03:32 +00:00
Iain Sandoe fee3cccc6c [C++20][Modules] Improve handing of Private Module Fragment diagnostics.
This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.

This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is declared in
a definition domain, it shall be defined in that domain.

The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls.  There is no point in telling the user
that the import of a PMF object is missing - since such objects are never reachable
to an importer.  We still show the definition (as unreachable), to help point out
this.

Differential Revision: https://reviews.llvm.org/D128328
2022-08-21 10:19:46 +01:00
Sam McCall ac31781759 [Sema] Tweak diagnostic logic so suppress-in-header logic works in tools too.
Certain idioms are ignored by -Wunused in header files only.
The current "is a header" check assumes that if headers are the main file, we're
building a PCH or a module or something. However in tools we may be parsing the
header in its own right, but still want to treat it as a header.

Fixes https://github.com/clangd/vscode-clangd/issues/360

Differential Revision: https://reviews.llvm.org/D129642
2022-08-19 15:16:10 +02:00
Timm Bäder 3d2ab237f1 [clang] Improve diagnostics for uninitialized constexpr variables
Instead of complaining about default initialization, tell users that
constexpr variables need to be initialized by a constant expression.

Differential Revision: https://reviews.llvm.org/D131662
2022-08-19 08:06:12 +02:00
Roy Jacobson 68786f0632 [Sema] Fix friend destructor declarations after D130936
I accidentally broke friend destructor declarations in D130936.

Modify it to skip performing the destructor name check if we have a dependent friend declaration.

Reviewed By: hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D131541
2022-08-16 22:28:19 +03:00
Nico Weber aacf1a9742 Revert "[clang] adds unary type transformations as compiler built-ins"
This reverts commit bc60cf2368.
Doesn't build on Windows and breaks gcc 9 build, see
https://reviews.llvm.org/D116203#3722094 and
https://reviews.llvm.org/D116203#3722128

Also revert two follow-ups. One fixed a warning added in
bc60cf2368, the other
makes use of the feature added in bc60cf2368
in libc++:

Revert "[libcxx][NFC] utilises compiler builtins for unary transform type-traits"
This reverts commit 06a1d917ef.

Revert "[Sema] Fix a warning"
This reverts commit c85abbe879.
2022-08-14 15:58:21 -04:00
Christopher Di Bella bc60cf2368 [clang] adds unary type transformations as compiler built-ins
Adds

* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`

These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.

[1]: http://wg21.link/meta.trans

Co-authored-by: zoecarver

Reviewed By: aaron.ballman, rsmith

Differential Revision: https://reviews.llvm.org/D116203
2022-08-14 17:12:15 +00:00
Florian Hahn ef110a491f
[Builtins] Do not claim most libfuncs are readnone with trapping math.
At the moment, Clang only considers errno when deciding if a builtin
is const. This ignores the fact that some library functions may raise
floating point exceptions, which may modify global state, e.g. when
updating FP status registers.

To model the fact that some library functions/builtins may raise
floating point exceptions, this patch adds a new 'g' modifier for
builtins. If a builtin is marked with 'g', it cannot be considered
const, unless FP exceptions are ignored.

So far I've not added CHECK lines for all calls in math-libcalls.c. I'll
do that once we agree on the overall direction.

A consequence seems to be that we fail to select some of the constrained
math builtins now, but I am not entirely sure what's going on there.

Reviewed By: john.brawn

Differential Revision: https://reviews.llvm.org/D129231
2022-08-11 12:29:01 +01:00
Aaron Ballman 4c02ab8c97 Change prototype merging error into a warning for builtins
As was observed in https://reviews.llvm.org/D123627#3707635, it's
confusing that a user can write:
```
float rintf(void) {}
```
and get a warning, but writing:
```
float rintf() {}
```
gives an error. This patch changes the behavior so that both are
warnings, so that users who have functions which conflict with a
builtin identifier can still use that identifier as they wish.

Differential Revision: https://reviews.llvm.org/D131499
2022-08-09 11:36:48 -04:00
Ilya Biryukov 07529996d9 [Sema] Merge variable template specializations
Clang used to produce redefinition errors, see tests for examples.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D131258
2022-08-09 12:17:41 +02:00
Fangrui Song 3f18f7c007 [clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC
With C++17 there is no Clang pedantic warning or MSVC C5051.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D131346
2022-08-08 09:12:46 -07:00
Xiang Li 8a27a2f89f [HLSL] Support -E option for HLSL.
-E option will set entry function for hlsl.
The format is -E entry_name.

To avoid conflict with existing option with name 'E', add an extra prefix '--'.

A new field HLSLEntry is added to TargetOption.
To share code with HLSLShaderAttr, entry function will be add HLSLShaderAttr attribute too.

Reviewed By: beanz

Differential Revision: https://reviews.llvm.org/D124751
2022-08-04 16:54:19 -07:00
Corentin Jabot 127bf44385 [Clang][C++20] Support capturing structured bindings in lambdas
This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.

In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.

We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.

In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.

Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.

at the request of @shafik, i can confirm the correct behavior of lldb wit this change.

Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D122768
2022-08-04 10:12:53 +02:00
Corentin Jabot a274219600 Revert "[Clang][C++20] Support capturing structured bindings in lambdas"
This reverts commit 44f2baa380.

Breaks self builds and seems to have conformance issues.
2022-08-03 21:00:29 +02:00
Corentin Jabot 44f2baa380 [Clang][C++20] Support capturing structured bindings in lambdas
This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.

In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.

We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.

In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.

Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.

at the request of @shafik, i can confirm the correct behavior of lldb wit this change.

Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D122768
2022-08-03 20:00:01 +02:00
Roy Jacobson 508c431ed9 [SemaCXX] Validate destructor is valid for dependent classes
We didn't check that a destructor's name matches the directly enclosing class if the class was dependent.
I enabled the check we already had for non-dependent types, which seems to work. Added appropriate tests.

Fixes GitHub issue #56772

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D130936
2022-08-02 21:50:54 +03:00
Gabriel Ravier 5674a3c880 Fixed a number of typos
I went over the output of the following mess of a command:

(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z |
 parallel --xargs -0 cat | aspell list --mode=none --ignore-case |
 grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n |
 grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)

and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).

Differential Revision: https://reviews.llvm.org/D130827
2022-08-01 13:13:18 -04:00
Chuanqi Xu 4d9251bd78 [C++20] [Modules] Merge same concept decls in global module fragment
According to [basic.def.odr]p14, the same redeclarations in different TU
but not attached to a named module are allowed. But we didn't take care
of concept decl for this condition. This patch tries to fix this
problem.

Reviewed By: ilya-biryukov

Differention Revision: https://reviews.llvm.org/D130614
2022-07-29 10:50:27 +08:00
Matheus Izvekov 15f3cd6bfc
[clang] Implement ElaboratedType sugaring for types written bare
Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

---

Troubleshooting list to deal with any breakage seen with this patch:

1) The most likely effect one would see by this patch is a change in how
   a type is printed. The type printer will, by design and default,
   print types as written. There are customization options there, but
   not that many, and they mainly apply to how to print a type that we
   somehow failed to track how it was written. This patch fixes a
   problem where we failed to distinguish between a type
   that was written without any elaborated-type qualifiers,
   such as a 'struct'/'class' tags and name spacifiers such as 'std::',
   and one that has been stripped of any 'metadata' that identifies such,
   the so called canonical types.
   Example:
   ```
   namespace foo {
     struct A {};
     A a;
   };
   ```
   If one were to print the type of `foo::a`, prior to this patch, this
   would result in `foo::A`. This is how the type printer would have,
   by default, printed the canonical type of A as well.
   As soon as you add any name qualifiers to A, the type printer would
   suddenly start accurately printing the type as written. This patch
   will make it print it accurately even when written without
   qualifiers, so we will just print `A` for the initial example, as
   the user did not really write that `foo::` namespace qualifier.

2) This patch could expose a bug in some AST matcher. Matching types
   is harder to get right when there is sugar involved. For example,
   if you want to match a type against being a pointer to some type A,
   then you have to account for getting a type that is sugar for a
   pointer to A, or being a pointer to sugar to A, or both! Usually
   you would get the second part wrong, and this would work for a
   very simple test where you don't use any name qualifiers, but
   you would discover is broken when you do. The usual fix is to
   either use the matcher which strips sugar, which is annoying
   to use as for example if you match an N level pointer, you have
   to put N+1 such matchers in there, beginning to end and between
   all those levels. But in a lot of cases, if the property you want
   to match is present in the canonical type, it's easier and faster
   to just match on that... This goes with what is said in 1), if
   you want to match against the name of a type, and you want
   the name string to be something stable, perhaps matching on
   the name of the canonical type is the better choice.

3) This patch could expose a bug in how you get the source range of some
   TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
   which only looks at the given TypeLoc node. This patch introduces a new,
   and more common TypeLoc node which contains no source locations on itself.
   This is not an inovation here, and some other, more rare TypeLoc nodes could
   also have this property, but if you use getLocalSourceRange on them, it's not
   going to return any valid locations, because it doesn't have any. The right fix
   here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
   into the inner TypeLoc to get the source range if it doesn't find it on the
   top level one. You can use getLocalSourceRange if you are really into
   micro-optimizations and you have some outside knowledge that the TypeLocs you are
   dealing with will always include some source location.

4) Exposed a bug somewhere in the use of the normal clang type class API, where you
   have some type, you want to see if that type is some particular kind, you try a
   `dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
   ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
   Again, like 2), this would usually have been tested poorly with some simple tests with
   no qualifications, and would have been broken had there been any other kind of type sugar,
   be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
   The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
   into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
   For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.

5) It could be a bug in this patch perhaps.

Let me know if you need any help!

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D112374
2022-07-27 11:10:54 +02:00
Roman Rusyaev fec5ff2a32 [Clang] [P2025] Analyze only potential scopes for NRVO
Before the patch we calculated the NRVO candidate looking at the
variable's whole enclosing scope. The research in [P2025] shows that
looking at the variable's potential scope is better and covers more
cases where NRVO would be safe and desirable.

Many thanks to @Izaron for the original implementation.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119792
2022-07-26 18:57:10 +08:00
Shafik Yaghmour aea82d4551 [Clang] Fix how we set the NumPositiveBits on an EnumDecl to cover the case of single enumerator with value zero or an empty enum
Currently in Sema::ActOnEnumBody(...) when calculating NumPositiveBits we miss
the case where there is only a single enumerator with value zero and the case of
an empty enum. In both cases we end up with zero positive bits when in fact we
need one bit to store the value zero.

This PR updates the calculation to account for these cases.

Differential Revision: https://reviews.llvm.org/D130301
2022-07-25 16:01:01 -07:00
Zequan Wu d870a57563 [SemaCXX] Set promotion type for enum if its type is promotable to integer type even if it has no definition.
EnumDecl's promotion type is set either to the parsed type or calculated type
after completing its definition. When it's bool type and has no definition,
its promotion type is bool which is not allowed by clang.

Fixes #56560.

Differential Revision: https://reviews.llvm.org/D130210
2022-07-21 11:23:21 -07:00
Iain Sandoe 97af17c5ca re-land [C++20][Modules] Update handling of implicit inlines [P1779R3]
re-land fixes an unwanted interaction with module-map modules, seen in
Greendragon testing.

This provides updates to
[class.mfct]:
Pre C++20 [class.mfct]p2:
  A member function may be defined (8.4) in its class definition, in
  which case it is an inline member function (7.1.2)
Post C++20 [class.mfct]p1:
  If a member function is attached to the global module and is defined
  in its class definition, it is inline.

and
[class.friend]:
Pre-C++20 [class.friend]p5
  A function can be defined in a friend declaration of a
  class . . . . Such a function is implicitly inline.
Post C++20 [class.friend]p7
  Such a function is implicitly an inline function if it is attached
  to the global module.

We add the output of implicit-inline to the TextNodeDumper, and amend
a couple of existing tests to account for this, plus add tests for the
cases covered above.

Differential Revision: https://reviews.llvm.org/D129045
2022-07-21 09:17:01 +01:00
Jonas Devlieghere 888673b6e3
Revert "[clang] Implement ElaboratedType sugaring for types written bare"
This reverts commit 7c51f02eff because it
stills breaks the LLDB tests. This was  re-landed without addressing the
issue or even agreement on how to address the issue. More details and
discussion in https://reviews.llvm.org/D112374.
2022-07-14 21:17:48 -07:00
Matheus Izvekov 7c51f02eff
[clang] Implement ElaboratedType sugaring for types written bare
Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

---

Troubleshooting list to deal with any breakage seen with this patch:

1) The most likely effect one would see by this patch is a change in how
   a type is printed. The type printer will, by design and default,
   print types as written. There are customization options there, but
   not that many, and they mainly apply to how to print a type that we
   somehow failed to track how it was written. This patch fixes a
   problem where we failed to distinguish between a type
   that was written without any elaborated-type qualifiers,
   such as a 'struct'/'class' tags and name spacifiers such as 'std::',
   and one that has been stripped of any 'metadata' that identifies such,
   the so called canonical types.
   Example:
   ```
   namespace foo {
     struct A {};
     A a;
   };
   ```
   If one were to print the type of `foo::a`, prior to this patch, this
   would result in `foo::A`. This is how the type printer would have,
   by default, printed the canonical type of A as well.
   As soon as you add any name qualifiers to A, the type printer would
   suddenly start accurately printing the type as written. This patch
   will make it print it accurately even when written without
   qualifiers, so we will just print `A` for the initial example, as
   the user did not really write that `foo::` namespace qualifier.

2) This patch could expose a bug in some AST matcher. Matching types
   is harder to get right when there is sugar involved. For example,
   if you want to match a type against being a pointer to some type A,
   then you have to account for getting a type that is sugar for a
   pointer to A, or being a pointer to sugar to A, or both! Usually
   you would get the second part wrong, and this would work for a
   very simple test where you don't use any name qualifiers, but
   you would discover is broken when you do. The usual fix is to
   either use the matcher which strips sugar, which is annoying
   to use as for example if you match an N level pointer, you have
   to put N+1 such matchers in there, beginning to end and between
   all those levels. But in a lot of cases, if the property you want
   to match is present in the canonical type, it's easier and faster
   to just match on that... This goes with what is said in 1), if
   you want to match against the name of a type, and you want
   the name string to be something stable, perhaps matching on
   the name of the canonical type is the better choice.

3) This patch could exposed a bug in how you get the source range of some
   TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
   which only looks at the given TypeLoc node. This patch introduces a new,
   and more common TypeLoc node which contains no source locations on itself.
   This is not an inovation here, and some other, more rare TypeLoc nodes could
   also have this property, but if you use getLocalSourceRange on them, it's not
   going to return any valid locations, because it doesn't have any. The right fix
   here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
   into the inner TypeLoc to get the source range if it doesn't find it on the
   top level one. You can use getLocalSourceRange if you are really into
   micro-optimizations and you have some outside knowledge that the TypeLocs you are
   dealing with will always include some source location.

4) Exposed a bug somewhere in the use of the normal clang type class API, where you
   have some type, you want to see if that type is some particular kind, you try a
   `dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
   ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
   Again, like 2), this would usually have been tested poorly with some simple tests with
   no qualifications, and would have been broken had there been any other kind of type sugar,
   be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
   The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
   into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
   For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.

5) It could be a bug in this patch perhaps.

Let me know if you need any help!

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D112374
2022-07-15 04:16:55 +02:00
Kazu Hirata cb2c8f694d [clang] Use value instead of getValue (NFC) 2022-07-13 23:39:33 -07:00
Jonas Devlieghere 3968936b92
Revert "[clang] Implement ElaboratedType sugaring for types written bare"
This reverts commit bdc6974f92 because it
breaks all the LLDB tests that import the std module.

  import-std-module/array.TestArrayFromStdModule.py
  import-std-module/deque-basic.TestDequeFromStdModule.py
  import-std-module/deque-dbg-info-content.TestDbgInfoContentDequeFromStdModule.py
  import-std-module/forward_list.TestForwardListFromStdModule.py
  import-std-module/forward_list-dbg-info-content.TestDbgInfoContentForwardListFromStdModule.py
  import-std-module/list.TestListFromStdModule.py
  import-std-module/list-dbg-info-content.TestDbgInfoContentListFromStdModule.py
  import-std-module/queue.TestQueueFromStdModule.py
  import-std-module/stack.TestStackFromStdModule.py
  import-std-module/vector.TestVectorFromStdModule.py
  import-std-module/vector-bool.TestVectorBoolFromStdModule.py
  import-std-module/vector-dbg-info-content.TestDbgInfoContentVectorFromStdModule.py
  import-std-module/vector-of-vectors.TestVectorOfVectorsFromStdModule.py

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45301/
2022-07-13 09:20:30 -07:00
serge-sans-paille 66fa2847a7 [clang] Ignore DependentSizeArray in -Warray-parameter
Acknowledge we don't know how to handle those yet.
2022-07-13 14:58:23 +02:00
Matheus Izvekov bdc6974f92
[clang] Implement ElaboratedType sugaring for types written bare
Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D112374
2022-07-13 02:10:09 +02:00
Jonas Devlieghere c7fd7512a5
Revert "[C++20][Modules] Update handling of implicit inlines [P1779R3]"
This reverts commit ef0fa9f0ef as a follow up to b19d3ee712 which
reverted commit ac507102d2. See https://reviews.llvm.org/D126189 for
more details.
2022-07-11 13:59:41 -07:00
Iain Sandoe ef0fa9f0ef [C++20][Modules] Update handling of implicit inlines [P1779R3]
This provides updates to
[class.mfct]:
Pre C++20 [class.mfct]p2:
  A member function may be defined (8.4) in its class definition, in
  which case it is an inline member function (7.1.2)
Post C++20 [class.mfct]p1:
  If a member function is attached to the global module and is defined
  in its class definition, it is inline.

and
[class.friend]:
Pre-C++20 [class.friend]p5
  A function can be defined in a friend declaration of a
  class . . . . Such a function is implicitly inline.
Post C++20 [class.friend]p7
  Such a function is implicitly an inline function if it is attached
  to the global module.

We add the output of implicit-inline to the TextNodeDumper, and amend
a couple of existing tests to account for this, plus add tests for the
cases covered above.

Differential Revision: https://reviews.llvm.org/D129045
2022-07-09 16:06:32 +01:00
serge-sans-paille cc5b77273a [clang] Introduce -Warray-parameter
This warning exist in GCC[0] and warns about re-declarations of functions
involving arguments of array or pointer types of inconsistent kinds or forms.

This is not the exact same implementation as GCC's : there's no warning level
and that flag has no effect on -Warray-bounds.

[0] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Warning-Options.html#index-Wno-array-parameter

Differential Revision: https://reviews.llvm.org/D128449
2022-07-08 22:36:05 +02:00
Iain Sandoe bc2a6defc8 [C++20][Modules] Allow for redeclarations in partitions.
The existing provision is not sufficient, it did not allow for the cases
where an implementation partition includes the primary module interface,
or for the case that an exported interface partition is contains a decl
that is then implemented in a regular implementation unit.

It is somewhat unfortunate that we have to compare top level module names
to achieve this, since built modules are not necessarily available.

TODO: It might be useful to cache a hash of the primary module name if
this test proves to be a  significant load.

Differential Revision: https://reviews.llvm.org/D127624
2022-07-08 19:02:59 +01:00
Joseph Huber f892ddb3be [OpenMP] Add variant extension that applies to declarations
This patch adds a new extension to the `omp begin / end declare variant`
support that causes it to apply to function declarations as well. This
is explicitly not done in the standard, but can be useful in some
situations so we should provide it as an extension. This will allow us
to uniquely bind and overload existing definitions with a simple
declaration using variants.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D124624
2022-06-29 15:04:26 -04:00
Martin Boehme 86866107b8 [Clang] Fix: Restore warning inadvertently removed by D126061.
Before D126061, Clang would warn about this code

```
struct X {
    [[deprecated]] struct Y {};
};
```

with the warning

    attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration

D126061 inadvertently caused this warning to no longer be emitted. This patch
restores the previous behavior.

The reason for the bug is that after D126061, C++11 attributes applied to a
member declaration are no longer placed in `DS.getAttributes()` but are instead
tracked in a separate list (`DeclAttrs`). In the case of a free-standing
decl-specifier-seq, we would simply ignore the contents of this list. Instead,
we now pass the list on to `Sema::ParsedFreeStandingDeclSpec()` so that it can
issue the appropriate warning.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D128499
2022-06-28 08:52:58 +02:00
Kazu Hirata 97afce08cb [clang] Don't use Optional::hasValue (NFC)
This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.
2022-06-25 22:26:24 -07:00
Kazu Hirata 3b7c3a654c Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3.
2022-06-25 11:56:50 -07:00
Kazu Hirata aa8feeefd3 Don't use Optional::hasValue (NFC) 2022-06-25 11:55:57 -07:00
Stephen Long 186bea3750 [MSVC] Add initial support for MSVC pragma optimize
MSVC's pragma optimize turns optimizations on or off based on the list
passed. At the moment, we only support an empty optimization list.

i.e. `#pragma optimize("", on | off)`

From MSVC's docs:

| Parameter | Type of optimization                             |
|-----------|--------------------------------------------------|
| g         | Enable global optimizations. Deprecated          |
| s or t    | Specify short or fast sequences of machine code  |
| y         | Generate frame pointers on the program stack     |

https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D125723
2022-06-24 08:03:42 -07:00