OpenCL has a reserved operator (^^), the use of which was diagnosed as
an error (735c6cdebdcd4292928079cb18a90f0dd5cd65fb). However, OpenCL
also encourages working with the blocks language extension. This token
has a parsing ambiguity as a result. Consider:
unsigned x=0;
unsigned y=x^^{return 0;}();
This should result in y holding the value zero (0^0) through an
immediately invoked block call as the right-hand side of the xor
operator. However, it causes errors instead because of this reserved
token: https://godbolt.org/z/navf7jTv1
This token is still reserved in OpenCL 3.0, so we still wish to issue a
diagnostic for its use. However, we do not need to create a token for an
extension point that's been unused for about a decade. So this patch
moves the diagnostic from a parsing diagnostic to a lexing diagnostic
and no longer forms a single token. The diagnostic behavior is slightly
worse as a result, but still seems acceptable.
Part of the reason this is coming up is because WG21 is considering
using ^^ as a token for reflection, so this token may come back in the
future.
This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.
This change updates extension diagnostics to state that lambadas are a
"clang HLSL" extension (since we have no planned release yet to include
them), and that `auto` is a HLSL 202y extension when used in earlier
language modes.
Note: This PR does temporarily work around some differences between HLSL
2021 and 202x in Clang by changing test cases to explicitly specify
202x. A subsequent PR will update 2021's language flags to match 202x.
The comment describes "If the identifier was typo-corrected", but it
doesn't need to have been typo-corrected, just being annotated is enough
to retry.
The PR reapply https://github.com/llvm/llvm-project/pull/97308.
- Implement [CWG1815](https://wg21.link/CWG1815): Support lifetime
extension of temporary created by aggregate initialization using a
default member initializer.
- Fix crash that introduced in
https://github.com/llvm/llvm-project/pull/97308. In
`InitListChecker::FillInEmptyInitForField`, when we enter
rebuild-default-init context, we copy all the contents of the parent
context to the current context, which will cause the `MaybeODRUseExprs`
to be lost. But we don't need to copy the entire context, only the
`DelayedDefaultInitializationContext` was required, which is used to
build `SourceLocExpr`, etc.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
This reverts commit 45c8766973bb3bb73dd8d996231e114dcf45df9f
and 049512e39d96995cb373a76cf2d009a86eaf3aab.
This change triggers failed asserts on inputs like this:
struct a {
} constexpr b;
class c {
public:
c(a);
};
class B {
public:
using d = int;
struct e {
enum { f } g;
int h;
c i;
d j{};
};
};
B::e k{B::e::f, int(), b};
Compiled like this:
clang -target x86_64-linux-gnu -c repro.cpp
clang: ../../clang/lib/CodeGen/CGExpr.cpp:3105: clang::CodeGen::LValue
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(const clang::DeclRefExpr*):
Assertion `(ND->isUsed(false) || !isa<VarDecl>(ND) || E->isNonOdrUse() ||
!E->getLocation().isValid()) && "Should not use decl without marking it used!"' failed.
Refactor attribute parsing so that the main code parsing an attribute
can be called by a separate code path that doesn't start with the
'__attribute' keyword.
Added a new `-Wpre-c++26-compat` warning for when this feature is used
in C++26 and a `-Wc++26-extensions` warning for when this is used in
C++11 through C++23.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
We only check that a default argument is a converted constant expression
when using the default argument.
However, when parsing a default argument, we need to make sure to parse
it as a constant expression such as not ODR-use variables. (otherwise,
we would try to capture default template arguments of generic lambdas)
Fixes#107048
There are currently no diagnostics being emitted for when a resource is
bound to a register with an incorrect binding type prefix. For example,
a CBuffer type resource should be bound with a a binding type prefix of
'b', but if instead the prefix is 'u', no errors will be emitted. This
PR implements such diagnostics. The focus of this PR is to implement
both the flag setting and diagnostic emisison steps specified in the
relevant spec: https://github.com/microsoft/hlsl-specs/pull/230
The relevant issue is: https://github.com/llvm/llvm-project/issues/57886
This is a continuation / refresh of this PR:
https://github.com/llvm/llvm-project/pull/87578
Diagnose this early after parsing declaration specifiers; this allows us
to issue a better diagnostic. This also checks for `concept friend` and
concept declarations w/o a template-head because it’s easiest to do that
at the same time.
Fixes#45182.
This patch adds a parser check when a function declaration or function
type declaration (in a function pointer declaration, for example) has
too many parameters for `FunctionTypeBits::NumParams` to hold. At the
moment of writing it's a 16-bit-wide bit-field, limiting the number of
parameters at 65536.
The check is added in the parser loop that goes over comma-separated
list of function parameters. This is not the solution Aaron suggested in
https://github.com/llvm/llvm-project/issues/35741#issuecomment-1638086571,
because it was found out that it's quite hard to recover from this
particular error in `GetFullTypeForDeclarator()`. Multiple options were
tried, but all of them led to crashes down the line.
I used LLVM Compile Time Tracker to ensure this does not introduce a
performance regression. I believe changes are in the noise:
https://llvm-compile-time-tracker.com/compare.php?from=de5ea2d122c31e1551654ff506c33df299f351b8&to=424818620766cedb2770e076ee359afeb0cc14ec&stat=instructions:uFixes#35741
When various `Sema*.h` and `Sema*.cpp` files were created, cleanup of
`Sema.h` includes and forward declarations was left for the later.
Now's the time. This commit touches `Sema.h` and Sema components:
1. Unused includes are removed.
2. Unused forward declarations are removed.
3. Missing includes are added (those files are largely IWYU-clean now).
4. Includes were converted into forward declarations where possible.
As this commit focuses on headers, all changes to `.cpp` files were
minimal, and were aiming at keeping everything buildable.
When incremental processing is enabled, the Parser will never report
tok::eof but tok::annot_repl_input_end. However, that case is already
taken care of in IncrementalParser::ParseOrWrapTopLevelDecl() so this
check was never executing.
In 2acf77f987331c05520c5bfd849326909ffce983 code was added to use the
'full' name including syntax and scope.
Instead of building up a large string for each name, add syntax and
scope checks to the value expression in tablegen.
There is already code to generate expressions for target specific
attributes. This change refactors and adds to that code to include
syntax and scope checks.
The tablegen avoids generating the complicated expression unless there
are two attributes using the same name, otherwise the case values will
be as simple as before.
Removes the currently unused attributeHasStrictIdentifierArgAtIndex
function and the related tablegen.
By the OpenMP standard, `num_teams` clause can only accept one
expression (for now). In this patch, we extend it to allow to accept
multiple expressions when it is used with `target teams ompx_bare`
construct. This will allow to launch a multi-dim grid, same as CUDA/HIP.
HLSL has a set of intangible types which are described in in the
[draft HLSL Specification
(**[Basic.types]**)](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf):
There are special implementation-defined types such as handle types,
which fall into a category of standard intangible types. Intangible
types are types that have no defined object representation or value
representation, as such the size is unknown at compile time.
A class type T is an intangible class type if it contains an base
classes or members of intangible class type, standard intangible type,
or arrays of such types. Standard intangible types and intangible class
types are collectively called intangible
types([9](https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Intangible)).
This PR implements one standard intangible type `__hlsl_resource_t`
and sets up the infrastructure that will make it easier to add more
in the future, such as samplers or raytracing payload handles. The
HLSL intangible types are declared in
`clang/include/clang/Basic/HLSLIntangibleTypes.def` and this file is
included with related macro definition in most places that require edits
when a new type is added.
The new types are added as keywords and not typedefs to make sure they
cannot be redeclared, and they can only be declared in builtin implicit
headers. The `__hlsl_resource_t` type represents a handle to a memory
resource and it is going to be used in builtin HLSL buffer types like this:
template <typename T>
class RWBuffer {
[[hlsl::contained_type(T)]]
[[hlsl::is_rov(false)]]
[[hlsl::resource_class(uav)]]
__hlsl_resource_t Handle;
};
Part 1/3 of llvm/llvm-project#90631.
---------
Co-authored-by: Justin Bogner <mail@justinbogner.com>
This is a minimal patch to support parsing for "omp assume" directives.
These are meant to be hints to a compiler's optimisers: as such, it is
legitimate (if not very useful) to ignore them. The patch builds on top
of the existing support for "omp assumes" directives (note spelling!).
Unlike the "omp [begin/end] assumes" directives, "omp assume" is
associated with a compound statement, i.e. it can appear within a
function. The "holds" assumption could (theoretically) be mapped onto
the existing builtin "__builtin_assume", though the latter applies to a
single point in the program, and the former to a range (i.e. the whole
of the associated compound statement).
This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
`is_null_pointer` can be implemented very efficiently as
`__is_same(__remove_cv(T), decltype(nullptr))`. Since GCC supports both
of these builtins as well, libc++ has no interest in using
`__is_nullptr` instead. Furthermore, I could find only a single use in
the wild
(https://sourcegraph.com/search?q=context:global+__is_nullptr%28+-file:clang&patternType=keyword&sm=0).
Because of these reasons I don't think it's worth keeping this builtin
around.
There are 5 unary operators that can be followed by a non-parenthesized
expression: `sizeof`, `__datasizeof`, `__alignof`, `alignof`,
`_Alignof`. When we nest them too deep, `BalancedDelimiterTracker` does
not help, because there are no parentheses, and we crash. Instead, this
patch recognize chains of those operators, and parse them with
sufficient stack space.
Fixes#45061
In 92fc1eb0c1ae3813f2ac9208e2c74207aae9d23 the HLSLLoopHint attribute
was added with an 'unroll' spelling. There is an existing LoopHint
attribute with the same spelling. These attributes have different
arguments.
The tablegen used to produce checks on arguments uses only the attribute
name, making it impossible to return correct info for attribute with
different argument types but the same name.
Improve the situation by using a 'full' name that combines the syntax,
scope, and name. This allows, for example, #pragma unroll and
[[unroll(x)]] to coexist correctly even with different argument types.
Also fix a bug in the StrictEnumParameters tablegen. If will now
correctly specify each parameter instead of only the first.
Consider the following:
```
template<typename T>
struct A { };
template<typename T>
int A<T>::B::* f(); // error: no member named 'B' in 'A<T>'
```
Although this is clearly valid, clang rejects it because the
_nested-name-specifier_ `A<T>::` is parsed as-if it was declarative,
meaning, we parse it as-if it was the _nested-name-specifier_ in a
redeclaration/specialization. However, we don't (and can't) know whether
the _nested-name-specifier_ is declarative until we see the '`*`' token,
but at that point we have already complained that `A` has no member
named `B`! This patch addresses this bug by adding support for _fully_
unannotated _and_ unbounded tentative parsing, which allows for us to
parse past tokens without having to cache them until we reach a point
where we can guarantee to be past the construct we are disambiguating.
I don't know where the approach taken here is ideal -- alternatives are
welcome. However, the performance impact (as measured by
llvm-compile-time-tracker (https://llvm-compile-time-tracker.com/?config=Overview&stat=instructions%3Au&remote=sdkrystian)
is quite minimal (0.09%, which I plan to further improve).
Fixes issue with defaultmap where scalar isn't handled correctly for
present modifier. Adds all variable cateogry introduced in OpenMP 5.2
and alters existing tests for error messages to check OpenMP 5.2
defaultmap messages.
`__is_layout_compatible` was added in Clang 19 (#81506), and at that
time it wasn't entirely clear whether it should be a revertible type
trait or not. We decided to follow the example of other type traits.
Since then #95969 happened, and now we know that we don't want new
revertible type traits.
This patch removes `__is_layout_compatible` from revertible type traits
list, and leaves a comment what revertible type traits are, and that new
type traits should not be added there.
The intention is to also cherry-pick this to 19 branch.
The builtin computes the discriminator for a type, which can be used to
sign/authenticate function pointers and member function pointers.
If the type passed to the builtin is a C++ member function pointer type,
the result is the discriminator used to signed member function pointers
of that type. If the type is a function, function pointer, or function
reference type, the result is the discriminator used to sign functions
of that type. It is ill-formed to use this builtin with any other type.
A call to this function is an integer constant expression.
Co-Authored-By: John McCall rjmccall@apple.com
It turns out `SemaTemplate` handles this type of diagnostic already,
however when template gets encountered, it never gets parsed as a
possible statement or declaration, only as an expression.
Fixes#17959.
`#pragma mc_func` is an IBM XL feature that should be replaced by inline
assembly. This PR adds an option `-ferr-pragma-mc-func-aix` to detect
uses of `#pragma mc_func` and reports an error if the option is in
effect. If `-fno-err-pragma-mc-func-aix` is in effect, `#pragma mc_func`
is ignored even if `-Werror=unknown-pragmas` is in effect.
It seems for C++ lexer has some caching ability which doesn't expect
injecting "new" tokens in the middle of the cache. Technically #embed
tokens are not completely new since they have already been read from the
file and there was #embed annotation token in this place, so set
`reinject` flag for them to silence assertion.
This PR implement [P3034R1 Module Declarations Shouldn’t be
Macros](https://wg21.link/P3034R1), and refactor the convoluted state
machines in module name lexical analysis.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Add the reverse directive which will be introduced in the upcoming
OpenMP 6.0 specification. A preview has been published in [Technical
Report 12](https://www.openmp.org/wp-content/uploads/openmp-TR12.pdf).
---------
Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
Instead of playing "whack a mole" with places where #embed should be
expanded as comma-separated list, just inject each byte as a token back
into the stream, separated by commas.
This reverts commit ce4aada6e2135e29839f672a6599db628b53295d and a
follow-up patch 8ef26f1289bf069ccc0d6383f2f4c0116a1206c1.
This new warning can not be fully suppressed by the
`-Wno-missing-dependent-template-keyword` flag, this gives developer no
time to do the cleanup in a large codebase, see https://github.com/llvm/llvm-project/pull/98547#issuecomment-2228250884
Constructs like `__is_pointer(Foo)` are never considered to be functions
declarations.
This matches usages in libstdc++, and we can hope
no one else redefine these reserved identifiers.
Fixes#95598
Previously, we only pushed the function scope once we entered the
function definition, whereas tryCaptureVariable() requires at least one
function scope available when ParmVarDecls being captured have been
owned by a function. This led to problems parsing the noexcept
specifiers, as the DeclRefExprs inside them were improperly computed.
Fixes https://github.com/llvm/llvm-project/issues/97453
Reapplies #92957, fixing an instance where the `template` keyword was
missing prior to a dependent name in `llvm/ADT/ArrayRef.h`. An
_alias-declaration_ is used to work around a bug affecting GCC releases
before 11.1 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799) which
rejects the use of the `template` keyword prior to the
_nested-name-specifier_ in the class member access.
