This fixes https://github.com/llvm/llvm-project/issues/64347.
The CTAD for an aggregate class is missing to handle the explicit type
conversion case, e.g. `TemplateFooClass(1, 2);`. Per C++ expr.type.conv
p1, the deduced type is the return type of the deduction guide selected
by the CTAD for the reminder.
In the deduction implementation
`DeduceTemplateSpecializationFromInitializer`, the parenthesized
express-list case relies on the `ParenListExpr` parameter (default is
nullptr), the AST `ParenListExpr` node is not built for all variant
initializer cases (`BuildCXXTypeConstructorExpr`, `BuildCXXNew` etc),
thus the deduction doesn't perform for these cases. This patch fixes it
by removing the `ParenListExpr` and using the `Inits` instead (which
also simplifies the interface and implementation).
There are many issues that popped up with the counted_by feature. The
patch #73730 has grown too large and approval is blocking Linux testing.
Includes reverts of:
commit 769bc11f68 ("[Clang] Implement the 'counted_by' attribute
(#68750)")
commit bc09ec6962 ("[CodeGen] Revamp counted_by calculations
(#70606)")
commit 1a09cfb2f3 ("[Clang] counted_by attr can apply only to C99
flexible array members (#72347)")
commit a76adfb992 ("[NFC][Clang] Refactor code to calculate flexible
array member size (#72790)")
commit d8447c78ab ("[Clang] Correct handling of negative and
out-of-bounds indices (#71877)")
Partial commit b31cd07de5 ("[Clang] Regenerate test checks (NFC)")
Closes#73168Closes#75173
Now we have default abi lp64 for rv64if and ilp32 for rv32if, which is
different with riscv-gnu-toolchain. In
8e9fb09a0c/configure (L3385)
when have f and not d, it prefers lp64f/ilp32f but no soft float. This
patch tries to make their behaviors consistent.
Current context set to where alias was met, not where it is declared
caused incorrect access check in case alias referenced private members
of the parent class.
This is a recommit of 6b1aa31 with a slight modification in order to fix
reported regression.
Fixes https://github.com/llvm/llvm-project/issues/41693
The checker EnumCastOutOfRange verifies the (helpful, but not
standard-mandated) design rule that integer to enum casts should not
produce values that don't have a corresponding enumerator. As it was
improved and cleaned up by recent changes, this commit renames it from
`alpha.cplusplus.EnumCastOutOfRange` to `optin.core.EnumCastOutOfRange`
to reflect that it's no longer alpha quality.
As this checker handles a basic language feature (which is also present
in plain C), I moved it to a "core" subpackage within "optin".
In addition to the renaming, this commit cleans up the documentation in
`checkers.rst` and adds the new example code to a test file to ensure
that it's indeed producing the behavior claimend in the documentation.
The constant evaluator could try to reference a lambda capture in a
static lambda call operator. Static lambdas can't have captures, so we
simply abort. Either the lambda needs to be made non-static, or the
capture (and reference to it) need to be removed.
Fixes: https://github.com/llvm/llvm-project/issues/74608
https://reviews.llvm.org/D154014 addes glob support and enables it when
`#!special-case-list-v2` is the first line. This patch makes the glob
support the default (faster than regex after
https://reviews.llvm.org/D156046) and switches to the deprecated regex
support if `#!special-case-list-v1` is the first line.
I have surveyed many ignore lists. All ignore lists I find only use
basic `*` `.` and don't use regex metacharacters such as `(` and `)`.
(As neither `src:` nor `fun:` benefits from using regex.)
They are unaffected by the transition (with a caution that regex
`src:x/a.pb.*` matches `x/axpbx` but glob `src:x/a.pb.*` doesn't).
There is no deprecating warning. If a user finds
`#!special-case-list-v1`, they shall read that the old syntax is
deprecated.
Link:
https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666
Per [[class.friend]p6](http://eel.is/c++draft/class.friend#6) a friend
function shall not be defined if its name isn't unqualified. A
_template-id_ is not a name, meaning that a friend function
specialization does not meet this criteria and cannot be defined.
GCC, MSVC, and EDG all consider friend function specialization
definitions to be invalid de facto explicit specializations and diagnose
them as such.
Instantiating a dependent friend function specialization definition
[currently sets off an assert](https://godbolt.org/z/Krqdq95hY) in
`FunctionDecl::setFunctionTemplateSpecialization`. This happens because
we do not set the `TemplateSpecializationKind` of the `FunctionDecl`
created by template argument deduction to `TSK_ExplicitSpecialization`
for friend functions
[here](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaTemplate.cpp#L9600).
I changed the assert condition because I believe this is the correct
behavior.
This commit introduces support for the MSVC-specific C++11-style
attribute `[[msvc::constexpr]]`, which was introduced in MSVC 14.33.
The semantics of this attribute are enabled only under
MSVC compatibility (`-fms-compatibility-version`) 14.33 and higher.
Additionally, the default value of `_MSC_VER` has been raised to 1433.
The current implementation lacks support for:
- `[[msvc::constexpr]]` constructors (see #72149);
at the time of this implementation, such support would have required
an unreasonable number of changes in Clang.
- `[[msvc::constexpr]] return ::new` (constexpr placement new) from
non-std namespaces (see #74924).
Relevant to: #57696
When emitting TBAA information for enums in C code we currently just
treat the data as an 'omnipotent char'. However, with C strict aliasing
this means we fail to optimise certain cases. For example, in the
SPEC2017 xz benchmark there are structs that contain arrays of enums,
and clang pessmistically assumes that accesses to those enums could
alias with other struct members that have a different type.
According to
https://en.cppreference.com/w/c/language/enum
enums should be treated as 'int' types unless explicitly specified (C23)
or if 'int' would not be large enough to hold all the enumerated values.
In the latter case the compiler is free to choose a suitable integer
that would hold all such values.
When compiling C code this patch generates TBAA information for the enum
by using an equivalent integer of the size clang has already chosen for
the enum. I have ignored C++ for now because the rules are more complex.
New test added here:
clang/test/CodeGen/tbaa.c
Summary:
The standard GNU atomic operations are a very common way to target
hardware atomics on the device. With more heterogenous devices being
introduced, the concept of memory scopes has been in the LLVM language
for awhile via the `syncscope` modifier. For targets, such as the GPU,
this can change code generation depending on whether or not we only need
to be consistent with the memory ordering with the entire system, the
single GPU device, or lower.
Previously these scopes were only exported via the `opencl` and `hip`
variants of these functions. However, this made it difficult to use
outside of those languages and the semantics were different from the
standard GNU versions. This patch introduces a `__scoped_atomic` variant
for the common functions. There was some discussion over whether or not
these should be overloads of the existing ones, or simply new variants.
I leant towards new variants to be less disruptive.
The scope here can be one of the following
```
__MEMORY_SCOPE_SYSTEM // All devices and systems
__MEMORY_SCOPE_DEVICE // Just this device
__MEMORY_SCOPE_WRKGRP // A 'work-group' AKA CUDA block
__MEMORY_SCOPE_WVFRNT // A 'wavefront' AKA CUDA warp
__MEMORY_SCOPE_SINGLE // A single thread.
```
Naming consistency was attempted, but it is difficult to capture to full
spectrum with no many names. Suggestions appreciated.
When checking if the constraint uses any enclosing template parameters
for [temp.friend]p9, if a containing record is used as argument, we
assume that the constraint depends on enclosing template parameters
without checking if the record is templated. The reproducer from the bug
is included as a test case.
Fixes#71595
Adds a warning, issued by the clang semantic analysis. The patch warns
on switch which don't have the default branch.
This is a counterpart of gcc's Wswitch-default.
Current context set to where alias was met, not where it is declared
caused incorrect access check in case alias referenced private members
of the parent class.
Fixes https://github.com/llvm/llvm-project/issues/41693
Currently target_clones attribute results in a linker error when there
are no multi-versioned function declarations in the calling TU.
In the calling TU, the call is generated with the ‘normal’ assembly
name. This does not match any of the versions or the ifunc, since
version mangling includes a .versionstring, and the ifunc includes
.ifunc suffix. The linker error is not seen with GCC since the mangling
for the ifunc symbol in GCC is the ‘normal’ assembly name for function
i.e. no ifunc suffix.
This PR removes the .ifunc suffix to match GCC. It also adds alias with
the .ifunc suffix so as to ensure backward compatibility.
The changes exclude aarch64 target because the mangling for default
versions on aarch64 does not include a .default suffix and is the
'normal' assembly name, unlike other targets. It is not clear to me what
the correct behavior for this target is.
Old Phabricator review - https://reviews.llvm.org/D158666
---------
Co-authored-by: Tom Honermann <tom@honermann.net>
Error message:
```
In file included from ../src/amd/addrlib/src/core/addrobject.h:21:
../src/amd/addrlib/src/core/addrcommon.h:343:13: error: expected unqualified-id
out = ::_tzcnt_u32(mask);
^
/usr/lib/llvm-15/lib/clang/15.0.6/include/bmiintrin.h:74:27: note: expanded from macro '_tzcnt_u32'
#define _tzcnt_u32(a) (__tzcnt_u32((a)))
```
This is because both GCC/Clang doesn't support compiling the following
code:
```
#ifdef _MSC_VER
#include <intrin.h>
#else
#include <x86intrin.h>
#endif
int f(int a) {
return ::(_tzcnt_u32)(a);
}
```
This is because the return statement expects an expression or braced
init list: http://eel.is/c++draft/stmt.jump#general-1 but we really only
need to care about the expression form (there's no braces in sight).
Grammatically, the leading :: will parse as a qualified-id because it
matches the production for nested-name-specifier:
http://eel.is/c++draft/expr.prim.id.qual#nt:qualified-id That needs to
be followed by an unqualified-id
(http://eel.is/c++draft/expr.prim.id.unqual#nt:unqualified-id), but the
open paren does not match any of the grammar productions, so this is a
syntax error.
Closes: https://github.com/llvm/llvm-project/issues/64467
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
We used to assume that the CXXRecordDecl passed to the 1st argument
always had a definition. This is not true since a pointer to an
incomplete type was not excluded.
Fixes https://github.com/llvm/llvm-project/issues/63506
Fixes#18763
Remove warnings when using a signed char as an array bound if the char is a known positive constant.
This goes one step farther than gcc does.
For example given the following code
```c++
char upper[300];
int main() {
upper['a'] = 'A';
char b = 'a';
upper[b] = 'A';
const char c = 'a';
upper[c] = 'A';
constexpr char d = 'a';
upper[d] = 'A';
char e = -1;
upper[e] = 'A';
const char f = -1;
upper[f] = 'A';
constexpr char g = -1;
upper[g] = 'A';
return 1;
}
```
clang currently gives warnings for all cases, while gcc gives warnings
for all cases except for 'a' (https://godbolt.org/z/5ahjETTv3)
With the change there is no longer any warning for 'a', 'c', or 'd'.
Add a style option to specify the order that property attributes should
appear in ObjC property declarations (property attributes are things like
`nonatomic, strong, nullable`).
Closes#71323.
Differential Revision: https://reviews.llvm.org/D150083
Due to d0d2ee0e4b clang doesn't perform
qualified name lookup into the current instantiation when it has
dependent bases, because of that `getTypeName` call always returns null
for unknown specialization case. When there is a `typename` keyword,
`DependentNameType` is constructed instead of simply returning null.
This change attempts to do the same in case of `typename` absence.
Fixes https://github.com/llvm/llvm-project/issues/13826
Despite CWG2497 not being resolved, it is reasonable to expect the
following code to compile (and which is supported by other compilers)
```cpp
template<typename T> constexpr T f();
constexpr int g() { return f<int>(); } // #1
template<typename T> constexpr T f() { return 123; }
int k[g()];
// #2
```
To that end, we eagerly instantiate all referenced specializations of
constexpr functions when they are defined.
We maintain a map of (pattern, [instantiations]) independent of
`PendingInstantiations` to avoid having to iterate that list after each
function definition.
We should apply the same logic to constexpr variables, but I wanted to
keep the PR small.
Fixes#73232
Currently when parsing a nested requirement we attempt to balance parens
if we have a parameter list. This will fail in some cases of ill-formed
code and keep going until we fall off the token stream and crash. This
fixes the hand parsing by using SkipUntil which will properly flag if we
don't find the expected tokens.
Fixes: https://github.com/llvm/llvm-project/issues/73112
The internals manual seems like a more obvious home for the details
instead of hiding them away in a header file and relying on doxygen
output to document it publicly.
Both active C++ proposals (P1144 and P2786) agree that
`is_trivially_relocatable_v<int&>` and
`is_trivially_relocatable_v<int()>` should be false, not true. Only
complete object types can be trivially relocatable.
Fixes#67498
Just follow along with the reassociate pragma. This allows locally
setting the arcp fast math flag. Previously you could only access this
through the global -freciprocal-math.
Fixes#64798
- Support non-member functions and callable objects for size and data().
We previously tried to (badly) pick the best overload ourselves, in a
way that would only support member functions. We now leave clang
construct an unresolved member expression and call that, properly
performing overload resolution with callable objects and static
functions, consistent with the logic for `get` calls for structured
bindings.
- Support UDLs as message expression.
- Add tests and mark CWG2798 as resolved
