This implements the C++23 `[[assume]]` attribute.
Assumption information is lowered to a call to `@llvm.assume`, unless the expression has side-effects, in which case it is discarded and a warning is issued to tell the user that the assumption doesn’t do anything. A failed assumption at compile time is an error (unless we are in `MSVCCompat` mode, in which case we don’t check assumptions at compile time).
Due to performance regressions in LLVM, assumptions can be disabled with the `-fno-assumptions` flag. With it, assumptions will still be parsed and checked, but no calls to `@llvm.assume` will be emitted and assumptions will not be checked at compile time.
Admittedly a bit awkward, `visionos` is the correct and accepted
spelling for annotating availability for xrOS target triples. This patch
detects errors and handles cases when `xros` is mistakenly passed.
In addition, add APIs for introduced/deprecated/obsoleted versioning in
DarwinSDKInfo mappings.
This patch implements `__is_layout_compatible` intrinsic, which supports
`std::is_layout_compatible` type trait introduced in C++20
([P0466R5](https://wg21.link/p0466r5) "Layout-compatibility and
Pointer-interconvertibility Traits"). Name matches GCC and MSVC
intrinsic.
Basically, this patch exposes our existing machinery for checking for
layout compatibility and figuring out common initial sequences. Said
machinery is a bit outdated, as it doesn't implement
[CWG1719](https://cplusplus.github.io/CWG/issues/1719.html) "Layout
compatibility and cv-qualification revisited" and
[CWG2759](https://cplusplus.github.io/CWG/issues/2759.html)
"`[[no_unique_address]` and common initial sequence". Those defect
reports are considered out of scope of of this PR, but will be
implemented in subsequent PRs.
Partially addresses #48204
Our usual pattern when issuing an extension warning is to also issue a
default-off diagnostic about the keywords not being compatible with
standards before a certain point. This adds those diagnostics for C11
keywords.
- Sema::isSimpleTypeSpecifier return true for _Bool in c99 (currently
returns false for _Bool, regardless of C dialect). (Fixes#72203)
- replace the logic with a check for simple types and a proper check for
a valid keyword in the appropriate dialect
Co-authored-by: Carl Peto <CPeto@becrypt.com>
Implements https://isocpp.org/files/papers/P2662R3.pdf
The feature is exposed as an extension in older language modes.
Mangling is not yet supported and that is something we will have to do before release.
While investigating implementing 'var-list' generically for the variety
of clauses that support this syntax (an extensive list!) I discovered
that it includes 'compound types' and members of compound types, as well
as array sections.
This patch genericizes that function, and implements it in terms of an
assignment expression, and enables a simplified version of OMP Array
Sections for it. OpenACC only supports a startidx + length, so this
patch implements that parsing.
However, it is currently still being represented as an OpenMP Array
Section, which is semantically very similar. It is my intent to come
back and genericize the OMP Array Sections types (or create a similar
expression node) in the future when dealing with Sema.
At the moment, the only obvious problem with it is that the diagnostic
for using it in the 'wrong' place says OpenMP instead of OpenACC, which
I intend to fix when I deal with the AST node changes.
The data size is required for implementing the `memmove` optimization
for `std::copy`, `std::move` etc. correctly as well as replacing
`__compressed_pair` with `[[no_unique_address]]` in libc++. Since the
compiler already knows the data size, we can avoid some complexity by
exposing that information.
This patch converts `SourceLocExpr::IdentKind` into a scoped enum at namespace scope, making it eligible to be forward-declared. This is needed by `preferred_type` annotations on bit-fields.
Adds a new `__builtin_vectorelements()` function which returns the
number of elements for a given vector either at compile-time for
fixed-sized vectors, e.g., created via `__attribute__((vector_size(N)))`
or at runtime via a call to `@llvm.vscale.i32()` for scalable vectors,
e.g., SVE or RISCV V.
The new builtin follows a similar path as `sizeof()`, as it essentially
does the same thing but for the number of elements in vector instead of
the number of bytes. This allows us to re-use a lot of the existing
logic to handle types etc.
A small side addition is `Type::isSizelessVectorType()`, which we need
to distinguish between sizeless vectors (SVE, RISCV V) and sizeless
types (WASM).
This is the [corresponding
discussion](https://discourse.llvm.org/t/new-builtin-function-to-get-number-of-lanes-in-simd-vectors/73911).
The bounds of a c++ array is a _constant-expression_. And in C++ it is
also a constant expression.
But we also support VLAs, ie arrays with non-constant bounds.
We need to take care to handle the case of a consteval function (which
are specified to be only immediately called in non-constant contexts)
that appear in arrays bounds.
This introduces `Sema::isAlwayConstantEvaluatedContext`, and a flag in
ExpressionEvaluationContextRecord, such that immediate functions in
array bounds are always immediately invoked.
Sema had both `isConstantEvaluatedContext` and
`isConstantEvaluated`, so I took the opportunity to cleanup that.
The change in `TimeProfilerTest.cpp` is an unfortunate manifestation of
the problem that #66203 seeks to address.
Fixes#65520
This reverts commit 491b2810fb7fe5f080fa9c4f5945ed0a6909dc92.
This change broke valid code and generated incorrect diagnostics, see
https://reviews.llvm.org/D155064
This patch makes clang diagnose extensive cases of consteval if and is_constant_evaluated usage that are tautologically true or false.
This introduces a new IsRuntimeEvaluated boolean flag to Sema::ExpressionEvaluationContextRecord that means the immediate appearance of if consteval or is_constant_evaluated are tautologically false(e.g. inside if !consteval {} block or non-constexpr-qualified function definition body)
This patch also pushes new expression evaluation context when parsing the condition of if constexpr and initializer of constexpr variables so that Sema can be aware that the use of consteval if and is_consteval are tautologically true in if constexpr condition and constexpr variable initializers.
BEFORE this patch, the warning for is_constant_evaluated was emitted from constant evaluator. This patch moves the warning logic to Sema in order to diagnose tautological use of is_constant_evaluated in the same way as consteval if.
This patch separates initializer evaluation context from InitializerScopeRAII.
This fixes a bug that was happening when user takes address of function address in initializers of non-local variables.
Fixes https://github.com/llvm/llvm-project/issues/43760
Fixes https://github.com/llvm/llvm-project/issues/51567
Reviewed By: cor3ntin, ldionne
Differential Revision: https://reviews.llvm.org/D155064
This is information that the compiler already has, and should be exposed
so that the library doesn't need to reimplement the exact same
functionality.
Differential Revision: https://reviews.llvm.org/D135341
I'm reverting this on principle, since it didn't get the Phabricator
approval I thought it had (only an informal LGTM). Will re-apply once
it has been properly approved.
This reverts commit e1bfeb6bcc627a94c5ab3a5417d290c7dc516d54.
This is information that the compiler already has, and should be exposed
so that the library doesn't need to reimplement the exact same
functionality.
Differential Revision: https://reviews.llvm.org/D135341
The attributes changes were left out of Clang 17.
Attributes that used to take a string literal now accept an unevaluated
string literal instead, which means they reject numeric escape sequences
and strings literal with an encoding prefix - but the later was already
ill-formed in most cases.
We need to know that we are going to parse an unevaluated string literal
before we do - so we can reject numeric escape sequence,
so we derive from Attrs.td which attributes parameters are expected
to be string literals.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D156237
This does the rename for most internal uses of C2x, but does not rename
or reword diagnostics (those will be done in a follow-up).
I also updated standards references and citations to the final wording
in the standard.
Predefined identifiers like __FUNCTION__ are treated like string
literals in MSVC, which means they can be concatentated together with
an adjacent string literal. Clang now supports this behavior as well,
in Microsoft extensions mode.
Fixes https://github.com/llvm/llvm-project/issues/63563
Differential Revision: https://reviews.llvm.org/D153914
This patch proposes to handle in an uniform fashion
the parsing of strings that are never evaluated,
in asm statement, static assert, attrributes, extern,
etc.
Unevaluated strings are UTF-8 internally and so currently
behave as narrow strings, but these things will diverge with
D93031.
The big question both for this patch and the P2361 paper
is whether we risk breaking code by disallowing
encoding prefixes in this context.
I hope this patch may allow to gather some data on that.
Future work:
Improve the rendering of unicode characters, line break
and so forth in static-assert messages
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D105759
_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type matched is the type after lvalue conversion. This conversion loses
type information, which makes it more difficult to match against
qualified or incomplete types.
This extension allows _Generic to accept a type operand instead of an
expression operand. The type operand form does not undergo any
conversions and is matched directly against the association list.
This extension is also supported in C++ as we already supported
_Generic selection expressions there.
The RFC for this extension can be found at:
https://discourse.llvm.org/t/rfc-generic-selection-expression-with-a-type-operand/70388
Differential Revision: https://reviews.llvm.org/D149904
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
Sema.h is huge. This makes a small reduction to it by moving
EnterExpressionEvaluationContext into a new header, since it is an
independent component.
Differential Revision: https://reviews.llvm.org/D149796
Add '__builtin_FILE_NAME()', which expands to the filename because the
full path is not always needed. It corresponds to the '__FILE_NAME__'
predefined macro and is consistent with the other '__builin' functions
added for predefined macros.
Differential Revision: https://reviews.llvm.org/D144878
This implements WG14 N2934
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2934.pdf), which
adds keywords for alignas, alignof, bool, static_assert, and
thread_local in C, as aliases for _Alignas, _Alignof, _Bool,
_Static_assert, and _Thread_local. We already supported the keywords in
C2x mode, but this completes support by adding pre-C2x compat warnings
and updates the stdalign.h header in freestanding mode.
This was a mistake from e7300e75b51a7e7d4e81975b4be7a6c65f9a8286
(https://reviews.llvm.org/D133574) caused by us accidentally tracking
an older copy of the C DR list for DR496. The text in
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_496 makes
it clear that subobjects are allowed, which means member and array
access expressions are allowed.
This backs out the changes from the previous commit that relate to this
diagnostic.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Reverts the revert of 39da55e8f548a11f7dadefa73ea73d809a5f1729
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Differential Revision: https://reviews.llvm.org/D133574
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This introduces support for nullptr and nullptr_t in C2x mode. The
proposal accepted by WG14 is:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm
Note, there are quite a few incompatibilities with the C++ feature in
some of the edge cases of this feature. Therefore, there are some FIXME
comments in tests for testing behavior that might change after WG14 has
resolved national body comments (a process we've not yet started). So
this implementation might change slightly depending on the resolution
of comments. This is called out explicitly in the release notes as
well.
Differential Revision: https://reviews.llvm.org/D135099
... as builtins.
This is information that the compiler already has, and should be exposed
so that the library doesn't need to reimplement the exact same
functionality.
This was originally a part of D116280.
Depends on D135175.
Differential Revision: https://reviews.llvm.org/D135177
This is information that the compiler already has, and should be exposed
so that the library doesn't need to reimplement the exact same
functionality.
This was originally a part of D116280.
Differential Revision: https://reviews.llvm.org/D135175
