A defaulted copy or move assignment operator for a union is synthesized
with an empty body. `DefineImplicitCopyAssignment` /
`DefineImplicitMoveAssignment` skip union members in the memberwise
loop, and the implied copy of the object representation has no AST
representation, a FIXME that has sat at that skip for a long time. The
operator ends up copying nothing.
Classic CodeGen hides this at ordinary call sites by lowering a trivial
assignment to a memcpy at the call site, so `u1 = u2` works even though
the operator body is a no-op. But when the operator is genuinely called,
through a pointer-to-member for instance, it silently copies nothing.
ClangIR calls the assignment operator at the call site rather than
eliding it, so it hits the empty body directly and drops every union
assignment. The no-op is then deleted at `-O3`. That is the MultiSource
`kc` miscompile, where a `YYSTYPE` union assignment (`*++yyvsp =
yylval`) becomes a no-op.
This implements the FIXME by mirroring the defaulted union copy
constructor (`CGClass.cpp`: "union copy constructor, we must emit a
memcpy") in the AST: when the class is a union,
`DefineImplicit{Copy,Move}Assignment` emits a single whole-object copy
through `buildMemcpyForAssignmentOp`, the helper already used for
trivially-copyable array members, instead of the skipped per-member
assignments. The operator stays trivial (triviality is fixed at
declaration time, before the body is synthesized), so constant
evaluation, which copies trivial unions through its own semantic path
and never executes the body, is unchanged.
Copying the object representation is correct even when a union member is
not trivially copyable, but the synthesized memcpy would then trip
`-Wnontrivial-memcall`. A `void*` cast would drop pointee qualifiers
such as the address space and inject an explicit cast node the source
never wrote. Instead the call keeps its typed union-pointer arguments,
and the union branch in `DefineImplicit{Copy,Move}Assignment` wraps the
build in `IgnoreAllWarningDiagRAII`, a save-and-restore around the
engine's existing ignore-all-warnings state. `CheckMemaccessArguments`
defers the warning and its note through `DiagRuntimeBehavior`, and that
queue flushes after the RAII has restored the previous ignore state, so
`DiagIfReachable` samples that state as it enqueues and drops what is
not error-class. Under `-w` the same queue is discarded before it
flushes, so nothing outside the scoped region changes.
Classic CodeGen now emits the copy when the operator is odr-used, and
ClangIR's union assignment lowers to a real memcpy. On the Sema side,
tests cover the synthesized AST for the implicit-`this` and C++23
explicit-object spellings, the `-Wnontrivial-memcall` suppression, the
preserved address space, the clean `-ast-print` output, and constexpr
active-member copy. The classic and ClangIR lowering is checked across
named, anonymous, and tail-padded unions.
#198918 added a defaulted-union `errorNYI` in ClangIR and deferred this
AST fix to a separate change. This PR makes that fix and drops the
guard, so the now-non-empty body lowers to a `cir.call @memcpy` instead
of erroring. Its own `union-copy-move-assignment.cpp` CIR test, which
expects that call, is the regression check.
`DiagnosticErrorTrap::hasErrorOccurred()` treats warnings promoted to
errors by `-Werror` as real errors, causing `BuiltinDumpStructGenerator`
to bail out before building the `PseudoObjectExpr` wrapper. CodeGen then
encounters the untransformed `CallExpr` with a placeholder builtin type
and hits `llvm_unreachable` in `CodeGenTypes::ConvertType`.
Use `hasUnrecoverableErrorOccurred()` instead, which ignores `-Werror`
promoted warnings and only bails on genuine compilation errors.
Fixes#211943
Adds a new `SpacesInBlockComments` clang-format option to control
spacing after `/*` and before `*/` in ordinary block comments.
Supported values:
* Always: formats `/*comment*/` as `/* comment */`
* Never: formats `/* comment */` as `/*comment*/`
* Leave: preserves existing spacing
Documentation comments such as `/** ... */` and `/*! ... */`, and
parameter comments such as `/*Arg=*/`, are left unchanged.
Tests added for all option values, multiline block comments, and
excluded parameter/doc comments.
Addresses #160682
Replace manual handling of 2 attributes with
`Sema::mergeDeclAttributes`, which is called during parsing too. Also
propagate attributes not from a previous redeclaration but from a
previous redeclaration outside of the current module. This is done to
avoid double propagation because attributes from a previous decl in the
same module are already handled when a module is built.
Call `ASTDeclReader::attachLatestDecl` after each decl is added to a
redeclaration chain, not once per `ASTReader::loadPendingDeclChain`
call. This is done to maintain correct redeclaration chain for each
`ASTDeclReader::attachPreviousDecl` call because [newly added]
`mergeDeclAttributes` requires a correct redeclaration chain.
Separated `Parser::Initialize` and `Parser::ConsumeToken` so can move
the initialization earlier, into `Parser` constructor. This way
`Parser::Initialize`, `Sema::Initialize`, `ASTReader::InitializeSema` are
executed before deserialization. This specific case is verified by
"Modules/decl-attr-merge-explicit-modules.c".
The change can cause compilation errors for downstream `Parser` clients.
Instead of calling `Parser::Initialize` now you need to call
`Parser::ConsumeToken`.
rdar://175997317
We have a libstdc++ workaround in place to address a hack in libstdc++15
that is used in the definition of `std::format_kind`. GCC accepts the
hack, while Clang does not. libstdc++ was eventually updated to remove
the hack, but we still need the workaround for some versions of
libstdc++15 (see #139560 for more information).
Whether this workaround (and others that address libstdc++ hacks) is
active depends on the value of `__GLIBCXX__`. This stops working if
someone first preprocesses the input (via `-E`) and then attempts to
compile the preprocessed code with Clang (see #160314): since
preprocessing has already happened, `__GLIBCXX__` will be undefined and
the workaround will not be applied.
In case of this particular workaround, this results in `#include
<format>` failing to compile on some versions of libstdc++ if you’re
using separate preprocessing.
To resolve this problem, this patch introduces a new pragma (`#pragma
clang __set_pp_state MACRO_NAME INTEGER`). This is intended as a general
solution to preserving preprocessor state across runs of the
preprocessor.
Currently, the only supported value for `MACRO_NAME`is `__GLIBCXX__`.
When we encounter this form of the pragma, we update
`Preprocessor::CXXStandardLibraryVersion` (we don’t actually define
`__GLIBCXX__` or do anything w/ that macro here). In `-E` mode, the
pragma is retained in the output, and a pragma is emitted for `#define
__GLIBCXX__` if printing macro definitions is disabled.
Things like `#undef __GLIBCXX__` and redefinitions of `__GLIBCXX__` are
deliberately left unhandled (i.e. you get what you get), since users
shouldn’t ever be undefining or redefining this macro anyway (and since
it starts w/ `__`, it would also be UB to do so).
Fixes#160314.
fixes https://github.com/llvm/llvm-project/issues/212109
From the edits to the release notes:
- On MIPS, a `_Complex` value with an integer element type is now
returned packed
into a single integer register when it fits in one, matching GCC. A
`_Complex char` or
`_Complex short`, and on N32/N64 also a `_Complex int`, is no longer
returned
with one part per register. `-fclang-abi-compat=23` restores the
previous
behavior. (#GH212109)
- On MIPS N32/N64, a `_Complex float` or `_Complex double` argument is
now packed
into integer registers, or onto the stack, once there is no longer room
to give
each of its parts a floating-point register, matching GCC. Clang
previously
always passed the parts separately. `-fclang-abi-compat=23` restores the
previous
behavior. (#GH212109)
This patch fixes a bug in handleMSPointerTypeQualifierAttr and
HandleWebAssemblyFuncrefAttr where applying these pointer attributes
would implicitly drop top-level CV qualifiers (like `const`, `volatile`,
and `restrict`) from the pointer type.
A doc comment can contain invalid UTF-8. The raw bytes reach
serializeDocComment, which assigned them to a llvm::json::Value,
tripping its valid-UTF-8 assertion. This is hit by legacy headers that
are not UTF-8 encoded, which compile fine but crash -extract-api.
Sanitize with json::isUTF8/fixUTF8 before serializing.
Fixes#212393
`ParseDeclaratorInternal's` member-pointer special case enters a
speculative scope-specifier parse whenever it sees `decltype`, without
checking that `( `follows:
```
if (getLangOpts().CPlusPlus &&
(Tok.is(tok::coloncolon) || Tok.is(tok::kw_decltype) || ...)) {
```
But `decltype-specifier` is always `decltype ( expression ) — decltype`
not followed by `(` can never be valid. When that happens,
`ParseOptionalCXXScopeSpecifier` still tries to parse it as one, fails,
and error recovery skips tokens. The EndLoc returned is then stale by
the time `AnnotateExistingDecltypeSpecifier` uses it to annotate, which
trips the invariant in `Preprocessor::AnnotatePreviousCachedTokens`:
```
int decltype; // crashed
int *decltype = 0; // crashed
```
Fix: only take this path when decltype is followed by (.
`(Tok.is(tok::kw_decltype) && NextToken().is(tok::l_paren)) ||`
`ParseDecltypeSpecifier` already requires `(` right after `decltype` or
bails with `TST_error`, so this check drops no valid parse —
`decltype(expr)` (including as a member-pointer scope, e.g.` int
decltype(obj)::*p = &S::m;) `is unaffected.
Fixes#211207
Co-authored - Claude-Sonnet
After the parameter declaration of a lambda expression, `Sema` enters
the declaration context of the lambda call operator (in
`ActOnLambdaClosureParameters`), so the lambda specifiers and the
trailing return type are analyzed within that context. Because of this,
predefined expressions such as `__func__` resolve to the lambda call
operator, and not to the possibly enclosing function. (issue #122657)
Added a member to `LambdaScopeInfo` to mark whether or not the compound
statement of the lambda expression has been entered, to be used when
resolving a `PredefinedExpr`
A class-type non-type template parameter is represented in the AST by a
TemplateParamObjectDecl, which has an empty DeclarationName.
USRGenerator had no visitor for it, so it fell through to
VisitNamedDecl, where EmitDeclName fails on the empty name and sets
IgnoreResults. That discarded the USR of the enclosing declaration.
Add a visitor that encodes the parameter object's type and value, so
specializations on distinct values get distinct USRs and equal values
agree.
Fixes#212351
When targeting aarch64-pc-windows-msvc, clang laid out a base following
an over-aligned, non-standard-layout base at the wrong offset. MSVC on
Arm64 reuses the over-aligned base's tail padding for the subsequent
base, but clang rounded the base up to a full slot, so the two disagreed
on member offsets, breaking interop between clang- and MSVC-built
binaries.
Fix: store each record's natural non-virtual alignment (excluding
`alignas`/`__declspec(align)` over-alignment) as
`getNonRequiredNVAlignment()`, and on Arm64 fold in a base's natural
alignment rather than its full alignment. This is gated to Arm64 only;
Arm64EC and x64 follow the x64 rule (no reuse) and are unchanged.
Validated against MSVC (Hostx64\arm64\cl.exe
/d1reportSingleClassLayout): clang now matches MSVC Arm64 exactly for
the reduced repro, the original polymorphic case (vftable + empty base +
template), and a range of probe cases covering natural vs.
over-alignment padding and field vs. base reuse. Arm64EC and x64 output
is byte-identical to before.
Fixes#210174
Abstract declarator contexts (specifically `DeclaratorContext::TypeName`) now properly bypass this restricted rule, allowing cv-qualified function types in `__typeof__` while maintaining restrictions in other contexts like `typeid`, `sizeof`, C-style casts, and `new` expressions per CWG1417.
```
int foo(){
int i = 42;
int j = 43;
auto l1 = [x = i, &j ](){};
}
```
in the lambda capture:
- `x` is visited as VariableRef (referencing an unvisited VarDecl at the
same location)
- `i` is visited as DelcRefExpr (fair enough, same as in an assignment)
- `j` is visited as VariableRef
Visit `x` as a `VarDecl`, and stop visiting it as a `VariableRef`, as it
makes no sense (referencing itself at an unvisited cursor).
---------
Co-authored-by: Serafean <Serafean@users.noreply.github.com>
StringRef assertion fires up when passing wide literals to
`__builtin_nanf()`.
The patch updates the `TryEvaluateBuiltinNan` method to reject
non-narrow string literals preventing the downstream assertion failure
caused by `getString()` in cases where the user might pass a non-narrow
/ non 1 byte literal."
Fix#205306
The implementation is quite straightforward. Compared to the FP or GP
register implementations, the main difference is that we need to
configure the vector registers before clearing them.
Now that the backend supports clearing all standard registers, this
patch makes the clang driver accept all -fzero-call-used-regs options.
Commit 68f703f3e5 added these release
notes, but this commit was backported to the 23.x release branch in
47e2df730a (included in the 23.1.0 RC 1
tag).
Therefore, remove these release notes from the main branch (where they
would have been included in the 24.x release notes).
Users and tools sometimes need to know which C++ standard library Clang
selected, and which include directories the driver added for it. Today
they have to inspect verbose or `-###` output.
Add options to print this information directly:
`--print-cxx-stdlib`
`--print-cxx-stdlib-include-dirs`
For MSVC targets, the default printed library is `msvcstl`. Explicit
`-stdlib=` values are still reported as requested. The include-dir query
reuses toolchain logic, including the MSVC STL include path for the
default MSVC case.
Fixes#210234
As per my investigation (mostly following stack traces and dumping
variable values), a default empty `DeclarationNameInfo` was being
returned after template substitution [over
here](c45b4e4d00/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp (L3270)).
```cpp
// D-.>getNameInfo() has actual data here
DeclarationNameInfo NameInfo
= SemaRef.SubstDeclarationNameInfo(D->getNameInfo(), TemplateArgs);
// NameInfo has default values
```
This was being passed on directly to `CXXDestructorDecl::Create` leading
to the assertion being hit. This PR adds a check that ensures `NameInfo`
actually contains a valid destructor name before constructing a
`CXXDestructorDecl`. This fixes the assertion being hit in the
reproducer from the linked issue.
Sema::isMemberAccessibleForDeletion treats AR_delayed as unreachable,
but CheckAccess returns AR_delayed whenever it runs inside an enclosing
delayed-diagnostics scope. That happens when deletion checking runs
synchronously while parsing a later declaration -- e.g. while explaining
why a defaulted operator<=> is deleted for an expression in that
declaration's initializer. The caller cannot consume a delayed
diagnostic, so letting CheckAccess delay always hits
llvm_unreachable("cannot delay =delete computation") and crashes.
Force an immediate answer by wrapping the CheckAccess call in
DelayedDiagnostics.pushUndelayed()/popUndelayed() via llvm::scope_exit,
mirroring the existing Sema::CheckEnableIf pattern in SemaOverload.cpp.
Fixes https://github.com/llvm/llvm-project/issues/210692
Co-authored-by: Claude-Sonnet
Fixes#210822
A `static` (or anonymous-namespace) function declared in the global
module fragment of the current TU is usable within the module unit
([module.global.frag]/p1), but `Sema::AddOverloadCandidate` dropped it
from the overload set when `Function->isInAnotherModuleUnit()` misfired
— which it does when the enclosing template is instantiated after the
GMF closes (pending instantiations run in
`ActOnEndOfTranslationUnitFragment`, before the named module is in
scope). The candidate was removed with the hidden
`ovl_fail_module_mismatched` kind, so the error had no candidate notes.
The existing carve-out (#104701) only exempted inline /
implicitly-instantiated GMF functions. This also exempts
internal-linkage functions from the current TU's GMF
(`isFromGlobalModule() && !isFromASTFile()`); genuinely imported
internal-linkage functions stay subject to the rule.
`clang/test/Modules` and `clang/test/CXX/module` show no new failures;
the `expose-static-inline-from-gmf-*` tests still pass. Adds a
regression test.
This change was developed with substantial assistance from an AI tool
(Claude Code). The AI carried out the investigation and root-cause
analysis, wrote the code change and the regression test, and drafted
this description.
This PR
- Use the recently introduced `EscapeSingleCodepointForDiagnostic` in
more places
- Fix a bug where U+FEFF was incorrectly treated as a BOM and therefore
did not render at all in diagnostics
Clang accepts some Unicode whitespaces in some context. There are a few
issues with this:
- The support is incomplete and inconsistent, as illustrated in #38934
- We are not consistent with the Unicode specs (tr1, tr55) in that we
treat U+0028/0+0029 as horizontal separators while Unicode consider them
vertical.
Ultimately, Unicode whitespaces are more likely than not unintended.
Neither GCC nor MSVC support this extension.
Fixes#38934.
## Summary
Fix an assertion failure when Clang classifies a built-in call with
type-dependent arguments before template instantiation, e.g., while
deducing an `auto` non-type template parameter:
For example:
```cpp
template <auto> struct S {};
template <typename T>
using Alias = S<__builtin_constant_p(T::x)>;
```
```
Assertion failed: (isa<T>(CanonicalType)), function castAs, file
TypeBase.h, line 9349.
#9 clang::Type::castAs<clang::FunctionType>() const
#10 clang::CallExpr::getCallReturnType(clang::ASTContext const&) const
#11 ClassifyInternal(clang::ASTContext&, clang::Expr const*)
#12 clang::Expr::ClassifyImpl(clang::ASTContext&,
clang::SourceLocation*) const
#13 clang::Sema::DeduceAutoType(...)
#14 clang::Sema::CheckTemplateArgument(...)
```
## Cause
Built-in references initially have the BuiltinFn placeholder type. For a non-dependent call, `BuildResolvedCallExpr()` applies `CK_BuiltinFnToFnPtr`, converting the callee to its function-pointer type.
When a call has type-dependent arguments, `BuildCallExpr()` postpones semantic analysis until instantiation. The callee, therefore, retains its BuiltinFn placeholder type. Deducing the auto non-type template parameter classifies the dependent call through `Expr::ClassifyImpl()`. This calls `CallExpr::getCallReturnType()`, which previously did not handle BuiltinFn and attempted to cast the placeholder to FunctionType, triggering an assertion.
The issue also affects ordinary builtins such as `__builtin_ffs` and is not specific to` __builtin_constant_p`.
## Fix
Handle `BuiltinFn` alongside the dependent and `Overload` callee cases in `CallExpr::getCallReturnType()` and return `DependentTy`. This matches the type `BuildCallExpr()` gives the `CallExpr` itself, so `getCallReturnType()` and `getType()` now agree on such calls.
Built-in resolution and built-in-specific type checking still occur as usual during template instantiation.
Added coverage for dependent calls and successful instantiation of `__builtin_constant_p` and `__builtin_ffs`, a non-dependent control case, and getCallReturnType() for a BuiltinFn callee.
The C and C++ standards require both operands of pointer subtraction to
refer to elements of the same array object. Clang/LLVM currently relies
on this rule in several optimizations:
- `inbounds` GEP introduces UB assumptions once the computed address
escapes the originating object bounds.
- `sdiv exact` assumes %op1 is divisable by %op2 otherwise it is a
poison value.
The first issue may be addressed with -fwrapv-pointer command line
option, however there is no option in clang to mitigate the second
issue. Patch adds a new -fdefined-pointer-subtraction to address this.
`Sema::ActOnParamDefaultArgument` checked a default-argument expression
for unexpanded parameter packs before checking whether the parameter
itself is a pack. For a lambda parameter pack given a default argument
that is a pack expansion referencing an enclosing function's parameter
pack (e.g. `[](Types... = args...) {}`), the first check runs while
still inside the lambda's scope and sets
`LambdaScopeInfo::ContainsUnexpandedParameterPack` (a mechanism meant
for legitimate outer-pack references). The subsequent
`isParameterPack()` check then correctly diagnoses the real error and
discards the default argument, but the stale flag survives into the
built `LambdaExpr`'s dependence bits. A later unexpanded-pack check on
that `LambdaExpr` finds nothing to report and hits
`assert(!Unexpanded.empty() || LambdaReferencingOuterPacks)`, aborting
instead of just diagnosing the error.
Fix: check `Param->isParameterPack()` first and return immediately after
discarding the default argument, before ever calling
`DiagnoseUnexpandedParameterPack` on an expression that is about to be
thrown away. [dcl.fct.default]p3 forbids a default argument on a pack
parameter unconditionally, so this ordering is also semantically
correct, not just a crash workaround.
Fixes#210714
This patch makes clang attempt printing enumerator names rather than
C-style cast expressions in more diagnostics (notably static_assert) iff
the value matches an enumerator exactly.
For example, consider a static assertion `static_assert(E ==
TestEnum::B);` where `E` is a constant template argument. Assuming
`(TestEnum)1 == TestEnum::A`, this changes emitted diagnostics as
follows:
```
// old
static assertion failed due to requirement '(TestEnum)1 == TestEnum::B'
// new
static assertion failed due to requirement 'TestEnum::A == TestEnum::B'
```
Variable and class templates weren't forwarding their declaration
attributes that were attached directly to them (at the moment, the only
one I could find that had this issue is the no_specialization attr). The
result was that intermediate redeclarations would prevent the
diagnostics from happening.
This patch ensures we propagate them properly for variable and class
templates. It seems our function templates already do the right thing.
Fixes: #209812
Add parsing and sema support for `dims` modifier (OpenMP 6.1) in `num_teams` and
`thread_limit` clauses. Example:
```cpp
constexpr int N = 2;
#pragma omp teams num_teams(dims(3): x, y, z) thread_limit(dims(N): a, b)
{ ... }
```
This closes https://github.com/llvm/llvm-project/issues/209427
The test currently crashes because while iterating over the candidate
members of an unresolved member expression, `decl` is a `UsingShadowDecl`
with underlying decl as `UnresolvedUsingValueDecl`.
The current `isa<UnresolvedUsingValueDecl>(decl)` guard only checks the
outer `UsingShadowDecl` and misses the unresolved-using decl hidden
inside it, so `getAsFunction()` returns nullptr and
`cast<CXXMethodDecl>(nullptr)` asserts.
This patch checks the `UnresolvedUsingValueDecl` inside by calling
`getUnderlyingDecl()` before the guard.
This used to happen before a2794f9f36.
Fixes https://github.com/llvm/llvm-project/issues/64706
Wire per function x86 AVX ABI level into CodeGen arrangement methods so
__attribute(__target("avx"))) / __attribute(__target("avx512f"))) on
methods, ctors, and free-functions affects ABI lowering consistently.
Specifically:
- Added X86AVXABILevel member to CGFunctionInfo.
- Populated X86AVXABILevel member in CGFunctionInfo objects via
arrangement methods declared in CodeGenTypes.h.
- Respect CGFunctionInfo AVX Level in X86_64ABIInfo::computeInfo.
- Add/extend regression tests for:
- free-function target-attribute AVX ABI lowering
- C++ method/ctor target-attribute AVX ABI lowering
- PS4/PS5 legacy ABI behavior (no per-function AVX ABI change)
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Reland #183004 and follow-up #205201 (reverted in #207840) which adds `-Wstringop-overread` to warn when memory functions `memcpy`, `memmove`, `memcmp`, and other related builtins read more bytes than the source buffer size.
The revert was due to a crash when a memory function is called on `&x` where `x` is a static constexpr local inside a template. The original PR exposed a bug in `computeDependence(UnaryOperator*)` where only the value-dependence bit is set for this case, when the instantiation-dependence bit should also be set. This is the root cause behind the crash.
Fix `computeDependence` to properly set both value and instantiation-dependence bits, and add a regression for this crash via `warn-stringop-overread.c`.
We were diagnosing this and leave the type in place, but that broke
invariants when
looking it up later. This patch just sets a fallback type to just the
'auto' (or a supported
type at least) instead, so that we gracefully continue.
Fixes: #208658
Following 6 OpenCL extensions are promoted to core features in 3.1:
https://github.com/KhronosGroup/OpenCL-Docs/commit/9fff1a87a975
- cl_khr_extended_bit_ops
- cl_khr_integer_dot_product
- cl_khr_subgroup_extended_types
- cl_khr_subgroup_rotate
- cl_khr_subgroup_shuffle
- cl_khr_subgroup_shuffle_relative
A target claiming OpenCL C 3.1 conformance without supporting one of
these features is now diagnosed.
Updated release notes for the change.
Assisted-by: Claude
Sema::UnusedLocalTypedefNameCandidates is populated while iterating a
Scope's
DeclsInScope, which is a SmallPtrSet whose iteration order depends on
pointer
values and is therefore not stable across runs. The candidates are
serialized
into the AST file -- both to assign declaration IDs and to write the
UNUSED_LOCAL_TYPEDEF_NAME_CANDIDATES record -- and are also used to emit
the
deferred -Wunused-local-typedef warnings, so neither the emitted PCH/AST
file
nor the diagnostics were reproducible. With deterministic compilation
caching
this surfaces as a "cache poisoned" error, because two builds of the
same PCH
produce different bytes.
Sort the candidates by source location at the point they are consumed,
via
Sema::getSortedUnusedLocalTypedefNameCandidates(), so that both the
diagnostics
and the serialized declarations are deterministic.
Deprecate these builtins with a warning recommending
__builtin_amdgcn_ballot_w32 or __builtin_amdgcn_ballot_w64 instead:
__builtin_amdgcn_uicmp
__builtin_amdgcn_uicmpl
__builtin_amdgcn_sicmp
__builtin_amdgcn_sicmpl
__builtin_amdgcn_fcmp
__builtin_amdgcn_fcmpf
Assisted-by: Claude Opus 4.8
`Sema::CheckCountedByAttrOnField()` in `SemaBoundsSafety.cpp` rejects
the `counted_by` family of attributes when the pointee is a struct that
contains a flexible array member (FAM). For example:
```
struct has_unannotated_fam {
int count;
int buffer[];
};
struct on_member_pointer_struct_with_fam {
int size;
struct has_unannotated_fam *objects __counted_by(size);
};
```
This restriction makes sense for `counted_by`/`counted_by_or_null`
because the size of a struct with a FAM is not statically known, so the
count of elements cannot be used to compute the size of the buffer.
However, the same check was incorrectly applied to `sized_by` and
`sized_by_or_null`. Unlike `counted_by`, these attributes describe the
size of the buffer in *bytes* rather than in *elements*, so the pointee
size is irrelevant and there is no ambiguity. Previously the following
would be rejected:
```
struct on_member_pointer_struct_with_fam {
int size;
struct has_unannotated_fam *objects __sized_by(size);
};
```
with the diagnostic:
```
error: 'sized_by' cannot be applied to a pointer with pointee of unknown
size because 'struct has_unannotated_fam' is a struct type with a
flexible array member
```
This patch guards the FAM check with `!CountInBytes` so that it only
applies to `counted_by`/`counted_by_or_null`. `sized_by` and
`sized_by_or_null` on such pointers are now correctly accepted.
The obsolete `expected-error` directives in the affected `sized_by` and
`sized_by_or_null` Sema tests are removed, turning those cases into
positive tests.
Assisted-by: Claude Code
rdar://182226884
Closing #173210
The self-assignment initialization `Type var = var;` is an idiom in C
code. The analyzer is expected to suppress the uninitialized assignment
reports and dead store reports for this idiom. Variables that are really
uninitialized will be reported until they are actually used. Since GCC
will not generate assembly code for such usage, even if under -O0
optimization (but Clang will), this patch resolves this problem by
ignoring such self-assigned `DeclStmt`s in the `ExprEngine`, as well as
in the `DeadStoreObs` of the dead store checker.
This ignorance will be applied to C variables and non-reference C++
variables. For record types in C++, since the constructors will always
be invoked, they will not be affected by this change.
