The document is mostly the exact copy of RFC: Enforcing Bounds Safety in
C, except some clarifications made over the PR review:
https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854
Further changes and clarifications for the programming model will be
done as separate patches to make it easier to track history of changes.
EnumConstantDecl is allocated by the ASTContext allocator so the
destructor is never called.
This patch takes a similar approach to IntegerLiteral by using
APIntStorage to allocate large APSInts using the ASTContext allocator as
well.
The downside is that an additional heap allocation and copy of the data
needs to be made when calling getInitValue if the APSInt is large.
Fixes#78160.
Adds support for the following matchers related to `CXXFoldExpr`:
`cxxFoldExpr`, `callee`,
`hasInit`, `hasPattern`, `isRightFold`, `isLeftFold`,
`isUnaryFold`, `isBinaryFold`, `hasOperator`, `hasLHS`, `hasRHS`.
This commit includes the necessary changes to clang and LLVM to support
codegen of `RVE` and the `ilp32e`/`lp64e` ABIs.
The differences between `RVE` and `RVI` are:
* `RVE` reduces the integer register count to 16(x0-x16).
* The ABI should be `ilp32e` for 32 bits and `lp64e` for 64 bits.
`RVE` can be combined with all current standard extensions.
The central changes in ilp32e/lp64e ABI, compared to ilp32/lp64 are:
* Only 6 integer argument registers (rather than 8).
* Only 2 callee-saved registers (rather than 12).
* A Stack Alignment of 32bits (rather than 128bits).
* ilp32e isn't compatible with D ISA extension.
If `ilp32e` or `lp64` is used with an ISA that has any of the registers
x16-x31 and f0-f31, then these registers are considered temporaries.
To be compatible with the implementation of ilp32e in GCC, we don't use
aligned registers to pass variadic arguments and set stack alignment\
to 4-bytes for types with length of 2*XLEN.
FastCC is also supported on RVE, while GHC isn't since there is only one
avaiable register.
Differential Revision: https://reviews.llvm.org/D70401
Fixes https://github.com/llvm/llvm-project/issues/51710.
When transforming a constructor into a corresponding deduction guide,
the decayed types (function/array type) were not handled properly which
made clang fail to compile valid code. The patch teaches clang handle
these decayed type in the transformation.
With modules, serialization might omit the outer ExprWithCleanups
as it calls ParmVarDecl::getDefaultArg(). Complementary to fixing
this in a separate change, make the code more robust by adding a
FullExpressionRAII and avoid the llvm_unreachable in the added test
clang/test/Modules/pr68702.cpp.
Closes https://github.com/llvm/llvm-project/issues/68702
Re-applies https://github.com/llvm/llvm-project/pull/69595 with extra
[diff](79181efd0d)
### New changes
Further relax ambiguities with a warning for member operators of a
template class (primary templates of such ops do not match). Eg:
```cpp
template <class T>
struct S {
template <typename OtherT>
bool operator==(const OtherT &rhs);
};
struct A : S<int> {};
struct B : S<bool> {};
bool x = A{} == B{}; // accepted with a warning.
```
This is important for making llvm build using previous clang versions in
C++20 mode (eg: this makes the commit
e558be51bab051d1471d92e967f8a2aecc13567a keep working with a warning
instead of an error).
### Description from https://github.com/llvm/llvm-project/pull/69595https://github.com/llvm/llvm-project/pull/68999 correctly computed
conversion sequence for reversed args to a template operator. This was a
breaking change as code, previously accepted in C++17, starts to break
in C++20.
Example:
```cpp
struct P {};
template<class S> bool operator==(const P&, const S &);
struct A : public P {};
struct B : public P {};
bool check(A a, B b) { return a == b; } // This is now ambiguous in C++20.
```
In order to minimise widespread breakages, as a clang extension, we had
previously accepted such ambiguities with a warning
(`-Wambiguous-reversed-operator`) for non-template operators. Due to the
same reasons, we extend this relaxation for template operators.
Fixes https://github.com/llvm/llvm-project/issues/53954
Fixes a crash where the template argument depth computed in the semantic
context for a friend FunctionDecl with a constrained parameter is
compared against arguments in the lexical context for the purpose of
checking if the constraint depends on enclosing template parameters.
Since getTemplateInstantiationArgs in this case follows the semantic DC
for friend FunctionDecls, the resulting depth is incorrect and trips an
assertion.
Fixes#75426
If DEFAULT_SYSROOT is not specfied when building flang, then the
-isysroot flag is needed to link binaries against system libraries
on Darwin. It's also needed when linking against a non-default
sysroot.
Fixes: #77583
bcd51aaaf8bde4b0ae7a4155d9ce3dec78fe2598 fixed part of template
instantiation dependent name issues but still missing some cases This
patch want to enhance the dependent name check
The 'counted_by' attribute is used on flexible array members. The
argument for the attribute is the name of the field member holding the
count of elements in the flexible array. This information is used to
improve the results of the array bound sanitizer and the
'__builtin_dynamic_object_size' builtin. The 'count' field member must
be within the same non-anonymous, enclosing struct as the flexible array
member. For example:
```
struct bar;
struct foo {
int count;
struct inner {
struct {
int count; /* The 'count' referenced by 'counted_by' */
};
struct {
/* ... */
struct bar *array[] __attribute__((counted_by(count)));
};
} baz;
};
```
This example specifies that the flexible array member 'array' has the
number of elements allocated for it in 'count':
```
struct bar;
struct foo {
size_t count;
/* ... */
struct bar *array[] __attribute__((counted_by(count)));
};
```
This establishes a relationship between 'array' and 'count';
specifically that 'p->array' must have *at least* 'p->count' number of
elements available. It's the user's responsibility to ensure that this
relationship is maintained throughout changes to the structure.
In the following, the allocated array erroneously has fewer elements
than what's specified by 'p->count'. This would result in an
out-of-bounds access not not being detected:
```
struct foo *p;
void foo_alloc(size_t count) {
p = malloc(MAX(sizeof(struct foo),
offsetof(struct foo, array[0]) + count *
sizeof(struct bar *)));
p->count = count + 42;
}
```
The next example updates 'p->count', breaking the relationship
requirement that 'p->array' must have at least 'p->count' number of
elements available:
```
void use_foo(int index, int val) {
p->count += 42;
p->array[index] = val; /* The sanitizer can't properly check this access */
}
```
In this example, an update to 'p->count' maintains the relationship
requirement:
```
void use_foo(int index, int val) {
if (p->count == 0)
return;
--p->count;
p->array[index] = val;
}
```
Function pointers are detected as a type of declaration using
FunctionTypeLParen. They are aligned based on rules for
AlignConsecutiveDeclarations. When a function pointer is on the
right-hand side of an assignment, the alignment of the function pointer
can result in excessive whitespace padding due to the ordering of
alignment, as the alignment processes a line from left-to-right and
first aligns the declarations before and after the assignment operator,
and then aligns the assignment operator. Injection of whitespace by
alignment of declarations after the equal sign followed by alignment of
the equal sign results in the excessive whitespace.
Fixes#68079.
This reverts commit fefdef808c230c79dca2eb504490ad0f17a765a5.
Breaks check-clang, see
https://github.com/llvm/llvm-project/pull/76348#issuecomment-1886029515
Also revert follow-on "[Clang] Update 'counted_by' documentation"
This reverts commit 4a3fb9ce27dda17e97341f28005a28836c909cfc.
The 'counted_by' attribute is used on flexible array members. The
argument for the attribute is the name of the field member holding the
count of elements in the flexible array. This information is used to
improve the results of the array bound sanitizer and the
'__builtin_dynamic_object_size' builtin. The 'count' field member must
be within the same non-anonymous, enclosing struct as the flexible array
member. For example:
```
struct bar;
struct foo {
int count;
struct inner {
struct {
int count; /* The 'count' referenced by 'counted_by' */
};
struct {
/* ... */
struct bar *array[] __attribute__((counted_by(count)));
};
} baz;
};
```
This example specifies that the flexible array member 'array' has the
number of elements allocated for it in 'count':
```
struct bar;
struct foo {
size_t count;
/* ... */
struct bar *array[] __attribute__((counted_by(count)));
};
```
This establishes a relationship between 'array' and 'count';
specifically that 'p->array' must have *at least* 'p->count' number of
elements available. It's the user's responsibility to ensure that this
relationship is maintained throughout changes to the structure.
In the following, the allocated array erroneously has fewer elements
than what's specified by 'p->count'. This would result in an
out-of-bounds access not not being detected:
```
struct foo *p;
void foo_alloc(size_t count) {
p = malloc(MAX(sizeof(struct foo),
offsetof(struct foo, array[0]) + count *
sizeof(struct bar *)));
p->count = count + 42;
}
```
The next example updates 'p->count', breaking the relationship
requirement that 'p->array' must have at least 'p->count' number of
elements available:
```
void use_foo(int index, int val) {
p->count += 42;
p->array[index] = val; /* The sanitizer can't properly check this access */
}
```
In this example, an update to 'p->count' maintains the relationship
requirement:
```
void use_foo(int index, int val) {
if (p->count == 0)
return;
--p->count;
p->array[index] = val;
}
```
This adds a new document that covers the HLSL approach to function calls
and parameter semantics. At time of writing this document is a proposal
for the implementation.
Part of https://reviews.llvm.org/D158218
GCC_INSTALL_PREFIX is a rarely-used legacy option inherited from
pre-CMake build system and has configuration file replacement nowadays.
Many `clang/test/Driver` tests specify `--gcc-toolchain=` to prevent
failures when `GCC_INSTALL_PREFIX` is specified: some contributors add
them to fix tests and some just do cargo culting. This is not healthy
for contributors adding cross compilation support for this rarely used
option.
`DEFAULT_SYSROOT` should in spirit be deprecated as well, but a relative
path doesn't have good replacement, so don't deprecate it for now.
Link:
https://discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091
Link:
https://discourse.llvm.org/t/correct-cmake-parameters-for-building-clang-and-lld-for-riscv/72833
---
With `GCC_INSTALL_PREFIX=/usr`, `clang a.c` behaves like
`clang --gcc-toolchain=/usr a.c`.
Here is a simplified version of GCC installation detection code.
```
if (OPT_gcc_install_dir_EQ)
return OPT_gcc_install_dir_EQ;
if (OPT_gcc_triple)
candidate_gcc_triples = {OPT_gcc_triple};
else
candidate_gcc_triples = collectCandidateTriples();
if (OPT_gcc_toolchain)
prefixes = {OPT_gcc_toolchain};
else
prefixes = {OPT_sysroot/usr, OPT_sysroot};
for (prefix : prefixes)
if "$prefix/lib/gcc" exists // also tries $prefix/lib/gcc-cross
for (triple : candidate_gcc_triples)
if "$prefix/lib/gcc/$triple" exists
return "$prefix/lib/gcc/$triple/$version"; // pick the largest version
```
`--gcc-toolchain=` specifies a directory where
`lib/gcc{,-cross}/$triple/$version` can be found. If you actually want
to use a specific version of GCC, specify something like
`--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11` in a configuration
file. You can also specify `--gcc-triple=`.
On Debian and its derivatives where the target triple omits the vendor
part, the following ways are roughly equivalent, except that
`--gcc-install-dir=` specifies a version as well:
```
clang --gcc-toolchain=/usr a.c
clang --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 a.c
clang --gcc-triple=x86_64-linux-gnu a.c
```
**Overview:**
Fix a bug where Clang's range-loop-analysis incorrectly checks for trivial copyability instead
of trivial copy constructibility, leading to erroneous warnings.
Fixes#47355
(42ec976184ac was reverted by 26993f61673e due to a use-after-scope bug.)
Reuse the patterns governing the previous input file being formatted if
the current input file is from the same directory.
Invalid (direct) initializer would invalid `VarDecl` so
`InitializerScopeRAII` cannot restore scope stack balance.
As with other kind of initializer, `InitializerScopeRAII::pop()` is
moved up before `Sema::ActOnInitializerError()` which invalidates the
`VarDecl`, so scope can be balanced and current `DeclContext` can be
restored.
Fixes#30908
Prior to this commit, it was impossible to use the simple string
matching directives to look for any content that contains unbalanced
`{{` `}}` pairs, such as:
```
// expected-note {{my_struct{{1}, 2}}}
```
Which would parse like so:
```
"nested" brace v
// expected-note {{my_struct{{1}, 2}}}
closes the nested brace ^ |
trailing }
```
And the frontend would complain 'cannot find end ('}}') of expected'.
At this snapshot, VerifyDiagnosticConsumer's parser now counts the
opening braces and looks for a matching length of closing sigils,
allowing the above to be written as:
```
// expected-note {{{my_struct{{1}, 2}}}}
opening brace |-| |-|
closing brace is '}}}', found here ^
```
This came about as a result of this discussion:
https://github.com/llvm/llvm-project/pull/74852#discussion_r1443117644
cc @erichkeane
Prior to this, attempts to bind a bit-field to an NTTP of reference type
produced an error because references to subobjects in NTTPs are
disallowed. But C++20 allows references to subobjects in NTTPs generally
(see
[P1907R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1907r1.html)).
Without this change, implementing P1907R1 would cause a bug allowing
bit-fields to be bound to reference template arguments.
Extracted from https://reviews.llvm.org/D140996
Fixes: #77411
When substituting deduced type, noexcept expr in method should be
instantiated and evaluated.
ThisScrope should be switched to method context instead of origin sema
context
This PR exposes four PGO functions
- `__llvm_profile_set_filename`
- `__llvm_profile_reset_counters`,
- `__llvm_profile_dump`
- `__llvm_orderfile_dump`
to user programs through the new header `instr_prof_interface.h` under
`compiler-rt/include/profile`. This way, the user can include the header
`profile/instr_prof_interface.h` to introduce these four names to their
programs.
Additionally, this PR defines macro `__LLVM_INSTR_PROFILE_GENERATE` when
the program is compiled with profile generation, and defines macro
`__LLVM_INSTR_PROFILE_USE` when the program is compiled with profile
use. `__LLVM_INSTR_PROFILE_GENERATE` together with
`instr_prof_interface.h` define the PGO functions only when the program
is compiled with profile generation. When profile generation is off,
these PGO functions are defined away and leave no trace in the user's
program.
Background:
https://discourse.llvm.org/t/pgo-are-the-llvm-profile-functions-stable-c-apis-across-llvm-releases/75832
Since Knight Landing and Knight Mill microarchitectures are EOL, we
would like to remove intrinsic supports for its specific ISA in LLVM 19.
In LLVM 18, we will first emit a warning for the usage.
When initializing a union that constrain a struct with a flexible array
member, and the initializer list is empty, we currently trigger an
assertion failure. This happens because getFlexibleArrayInitChars()
assumes that the initializer list is non-empty.
Fixes https://github.com/llvm/llvm-project/issues/77085.
This fixes the bug introduced by
6db007a065.
We construct placeholder template arguments for template-template
parameters to avoid mismatching argument substitution since they have
different depths with their corresponding template arguments. In this
case,
```cpp
template <template <Concept C> class T> void foo(T<int>);
```
T lies at the depth 0, and C lies at 1. The corresponding argument, of
which there is exactly one, int, is at depth 0. If we consider the
argument as the outermost one, then we would end up substituting 'int'
into the wrong parameter T.
We used to perform such placeholder construction during the context
walk-up. In the previous patch, we slipped through that inadvertently
because we would walk up to the parent, which is precisely a FileContext
for template-template parameters, after adding innermost arguments.
Besides, this patch moves the sanity check up to the context switch.
That way, we avoid dereferencing null pointers if ND is unspecified.
Closes https://github.com/llvm/llvm-project/issues/57410.
Closes https://github.com/llvm/llvm-project/issues/76604. (The case is
slightly different than that in #57410. We should *not* assume the
surrounding context to be a file-scope one.)
Fixes: #77071
`SubstituteDeducedTypeTransform` will transform type and it will visit
uninstantiated `ExceptionSpecInfo`, which will cause odd behavior.
Lifetime-bound analysis of reference parameters of coroutines and
coroutine wrappers is helpful in surfacing memory bugs associated with
using temporaries and stack variables in call expressions in plain
return statements.
This is the default semantics of `[[clang::coro_lifetimebound]]`. But it
should be okay to relax the requirements for a function when the
reference arguments are not lifetime bound. For example:
A coroutine wrapper accepts a reference parameter but does not pass it
to the underlying coroutine call.
```cpp
[[clang::coro_wrapper]] Task<int> wrapper(const Request& req) {
return req.shouldCallA() ? coroA() : coroB();
}
```
Or passes it the coroutine by value
```cpp
Task<int> coro(std::string s) { co_return s.size(); }
[[clang::coro_wrapper]] wrapper(const std::string& s) { return coro(s); }
```
This patch allows functions to be annotated with
`[[clang::coro_disable_lifetime_bound]]` to disable lifetime bound
analysis for all calls to this function.
---
One missing piece here is a note suggesting using this annotation in
cases of lifetime warnings. This would require some more tweaks in the
lifetimebound analysis to recognize violations involving coroutines only
and produce this note only in those cases.
Currently, due to the incomplete implementation of p0588r1, the
instantiation of lambda expressions leads to the instantiation of the
body. And `EvaluateConstraints` is false during the instantiation of the
body, which causes crashes during the instantiation of the return type
requirement:
```cpp
template<typename T> concept doesnt_matter = true;
template<class T>
concept test =
[]{
return requires(T t) {
{ t } -> doesnt_matter; // crash
};
}();
static_assert(test<int>);
```
Although a complete implementation of p0588r1 can solve these crashes,
it will take some time. Therefore, this pull request aims to fix these
crashes first.
Fixes https://github.com/llvm/llvm-project/issues/63808
Fixes https://github.com/llvm/llvm-project/issues/64607
Fixes https://github.com/llvm/llvm-project/issues/64086
This reapplies f034044ad94d6f7ccec13d89f08acac257ed28bb after it was
reverted by 687396b5f4ba0713d103ebd172b308e92eb930cc due to a test
failure in clang-doc.
The test in question declares a partial specialization of a function
template, as well as an explicit specialization of the same function
template. Both declarations are now set as invalid, meaning neither is
emitted by clang-doc.
Since this is the sole test of function template specializations in
clang-doc, I presume the intent is for the partial specialization to
actually be the primary template. Doing so results in the expected
output.
This reverts commit 42ec976184acd40436acd7104ad715c60ca3e7ed.
Reason: Broke the sanitizer buildbots. See more information on the
github comment thread at
42ec976184
