The order of operation was slightly incorrect, as we were checking for
incomplete types *before* handling reference types.
Fixes#129397
---------
Co-authored-by: Erich Keane <ekeane@nvidia.com>
When `ArePotentiallyOverlappingStringLiterals`, added in
https://github.com/llvm/llvm-project/pull/109208, compares string
literals it drops the front of the string with the greatest offset from
its base pointer. The number of characters dropped is equal to the
difference between the two strings' offsets from their base pointers.
This would trigger an assert when the resulting offset is past the end
of the object. Not only are one-past-the-end pointers legal constructs,
the compiler should not crash even when faced with illegal constructs.
rdar://149865910
This is a basic implementation of P2719: "Type-aware allocation and
deallocation functions" described at http://wg21.link/P2719
The proposal includes some more details but the basic change in
functionality is the addition of support for an additional implicit
parameter in operators `new` and `delete` to act as a type tag. Tag is
of type `std::type_identity<T>` where T is the concrete type being
allocated. So for example, a custom type specific allocator for `int`
say can be provided by the declaration of
void *operator new(std::type_identity<int>, size_t, std::align_val_t);
void operator delete(std::type_identity<int>, void*, size_t, std::align_val_t);
However this becomes more powerful by specifying templated declarations,
for example
template <typename T> void *operator new(std::type_identity<T>, size_t, std::align_val_t);
template <typename T> void operator delete(std::type_identity<T>, void*, size_t, std::align_val_t););
Where the operators being resolved will be the concrete type being
operated over (NB. A completely unconstrained global definition as above
is not recommended as it triggers many problems similar to a general
override of the global operators).
These type aware operators can be declared as either free functions or
in class, and can be specified with or without the other implicit
parameters, with overload resolution performed according to the existing
standard parameter prioritisation, only with type parameterised
operators having higher precedence than non-type aware operators. The
only exception is destroying_delete which for reasons discussed in the
paper we do not support type-aware variants by default.
C2y adds the `_Countof` operator which returns the number of elements in
an array. As with `sizeof`, `_Countof` either accepts a parenthesized
type name or an expression. Its operand must be (of) an array type. When
passed a constant-size array operand, the operator is a constant
expression which is valid for use as an integer constant expression.
This is being exposed as an extension in earlier C language modes, but
not in C++. C++ already has `std::extent` and `std::size` to cover these
needs, so the operator doesn't seem to get the user enough benefit to
warrant carrying this as an extension.
Fixes#102836
Handles #123121
This patch updates `note_constexpr_invalid_cast` diagnostic to use
`enum_select` instead of `select,` improving readability and reducing
reliance on magic numbers in caller sites.
Introduce a trait to determine the number of bindings that would be
produced by
```cpp
auto [...p] = expr;
```
This is necessary to implement P2300
(https://eel.is/c++draft/exec#snd.concepts-5), but can also be used to
implement a general get<N> function that supports aggregates
`__builtin_structured_binding_size` is a unary type trait that evaluates
to the number of bindings in a decomposition
If the argument cannot be decomposed, a sfinae-friendly error is
produced.
A type is considered a valid tuple if `std::tuple_size_v<T>` is a valid
expression, even if there is no valid `std::tuple_element`
specialization or suitable `get` function for that type.
Fixes#46049
Make the memory representation of boolean vectors in HLSL, vectors of
i32.
Allow boolean swizzling for boolean vectors in HLSL.
Add tests for boolean vectors and boolean vector swizzling.
Closes#91639
This implements the R2 semantics of P0963.
The R1 semantics, as outlined in the paper, were introduced in Clang 6.
In addition to that, the paper proposes swapping the evaluation order of
condition expressions and the initialization of binding declarations
(i.e. std::tuple-like decompositions).
Perform the check for constexpr-unknown values in the same place we
perform checks for other values which don't count as constant
expressions.
While I'm here, also fix a rejects-valid with a reference that doesn't
have an initializer. This diagnostic was also covering up some of the
bugs here.
The existing behavior with -fexperimental-new-constant-interpreter seems
to be correct, but the diagnostics are slightly different; it would be
helpful if someone could check on that as a followup.
Followup to #128409.
Fixes#129844. Fixes#129845.
In APFloat, we have defined maxnum and minnum, so let's use them
directly here.
In `maxnum`/`minnum` of APFloat, we process sNaN, signed-zero as
strictly as possible.
This patch fixes assertion failures in clang, caused by unique
properties of _mfp8 type, namely it not being either scalar or vector
type and it not being either integer or float type.
This merges the functionality of ResolvedUnexpandedPackExpr into
FunctionParmPackExpr. I also added a test to show that
https://github.com/llvm/llvm-project/issues/125103 should be fixed with
this. I put the removal of ResolvedUnexpandedPackExpr in its own commit.
Let me know what you think.
Fixes#125103
Implement HLSL Aggregate Splat casting that handles splatting for arrays
and structs, and vectors if splatting from a vec1.
Closes#100609 and Closes#100619
Depends on #118842
Implement HLSLElementwiseCast excluding support for splat cases
Do not support casting types that contain bitfields.
Partly closes#100609 and partly closes#100619
This is an implementation of P1061 Structure Bindings Introduce a Pack
without the ability to use packs outside of templates. There is a couple
of ways the AST could have been sliced so let me know what you think.
The only part of this change that I am unsure of is the
serialization/deserialization stuff. I followed the implementation of
other Exprs, but I do not really know how it is tested. Thank you for
your time considering this.
---------
Co-authored-by: Yanzuo Liu <zwuis@outlook.com>
This test:
```c++
extern Swim& trident; // expected-note {{declared here}}
constexpr auto& gallagher = typeid(trident); // expected-error {{constexpr variable 'gallagher' must be initialized by a constant expression}}
// expected-note@-1 {{initializer of 'trident' is not a constant expression}}
```
diagnosed the initializer of `trident` as not constant, but `trident`
doesn't even have an initializer. Remove that diagnostic in this case.
When implmenting P2280R4 here:
https://github.com/llvm/llvm-project/pull/95474
When creating the APValue to store and constexprUnknown value I used an
offset of CharUnits::One() but it should have been CharUnits::Zero().
This change just adjusts that value.
P2280R4 allows the use of references in pointers of unknown origins in a
constant expression context but only in specific cases that could be
constant expressions.
We track whether a variable is a constexpr unknown in a constant
expression by setting a flag in either APValue or LValue and using this
flag to prevent using unknown values in places where it is not allowed.
Fixes: https://github.com/llvm/llvm-project/issues/63139https://github.com/llvm/llvm-project/issues/63117
... between unrelated declarations or literals.
Leaving this small (I haven't run the whole test suite locally) to get
some feedback on the wording and implementation first.
The output of the sample in
https://github.com/llvm/llvm-project/issues/117409 is now:
```console
./array.cpp:57:6: warning: expression result unused [-Wunused-value]
57 | am - aj.af();
| ~~ ^ ~~~~~~~
./array.cpp:70:8: error: call to consteval function 'L::L<bx>' is not a constant expression
70 | q(0, [] {
| ^
./array.cpp:57:6: note: arithmetic on addresses of literals has unspecified value
57 | am - aj.af();
| ^
./array.cpp:62:5: note: in call to 'al(&""[0], {&""[0]})'
62 | al(bp.af(), k);
| ^~~~~~~~~~~~~~
./array.cpp:70:8: note: in call to 'L<bx>({})'
70 | q(0, [] {
| ^~~~
71 | struct bx {
| ~~~~~~~~~~~
72 | constexpr operator ab<g<l<decltype(""[0])>::e>::e>() { return t(""); }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
73 | };
| ~~
74 | return bx();
| ~~~~~~~~~~~~
75 | }());
| ~~~
```
The output for
```c++
int a, b;
constexpr int n = &b - &a
```
is now:
```console
./array.cpp:80:15: error: constexpr variable 'n' must be initialized by a constant expression
80 | constexpr int n = &b - &a;
| ^ ~~~~~~~
./array.cpp:80:22: note: arithmetic involving '&b' and '&a' has unspecified value
80 | constexpr int n = &b - &a;
| ^
1 error generated.
```
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g.
SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp:
lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
Save the bitwidth value as a `ConstantExpr` with the value set. Remove
the `ASTContext` parameter from `getBitWidthValue()`, so the latter
simply returns the value from the `ConstantExpr` instead of
constant-evaluating the bitwidth expression every time it is called.
This shows up in several places in order to match the quoting of other
uses of the same diagnostic. Handling it centrally simplifies the code
and reduces changes if the storage for builtin names changes.
This refactoring is extracted out of #120534 as requested in code
review.
