We document libstdc++4.8 as the minimum supported version, and we
carried a hack for `include/tr1/hashtable.h` fixed in 4.7.
Cleanup some libstdc++ compatibility comments.
I also fixed __builtin_wasm_ref_null_extern() to generate a diagnostic
when it gets an argument. It seems like `SemaRef.checkArgCount()` has a
bug that makes it unable to check for 0 args.
Since 346077aa, we began using the primary template's lexical
DeclContext for template arguments in order to properly instantiate a
friend definition.
There is a missed peculiar case, as in a friend template is specialized
within a dependent context. In this scenario, the primary template is
not a definition, whereas the specialization is. So the primary
template's DeclContext doesn't provide anything meaningful
for instantiation.
Fixes https://github.com/llvm/llvm-project/issues/139052
This just adds a warning for bitfields placed next to other bitfields
where the underlying type has different storage. Under the MS struct
bitfield packing ABI such bitfields are not packed.
When calling a function that expects zero arguments with one argument,
`Call->getArg(1)` will trap when trying to format the diagnostic.
This also seems to improve the rendering of the diagnostic some of the
time. Before:
```
$ ./bin/clang -c a.c
a.c:2:30: error: too many arguments to function call, expected 2, have 4
2 | __builtin_annotation(1, 2, 3, 4);
| ~ ^
```
After:
```
$ ./bin/clang -c a.c
a.c:2:30: error: too many arguments to function call, expected 2, have 4
2 | __builtin_annotation(1, 2, 3, 4);
| ^~~~
```
Split from #139580.
---------
Co-authored-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
We weren't correctly handling size expressions with errors before trying
to get the type of the size expression.
No release note needed because support for 'stripe' was added to the
current release.
Fixes#139433
C++ has a carve-out that makes a declaration with 'extern' explicitly
specified and no initializer be a declaration rather than a definition.
We now account for that to silence a diagnostic with:
```
extern const int i;
const int i = 12;
```
which is valid C++.
Addresses an issue that was brought up via post-commit review.
- Defines a new declaration node `HLSLRootSignature` in `DeclNodes.td`
that will consist of a `TrailingObjects` of the in-memory construction
of the root signature, namely an array of `hlsl::rootsig::RootElement`s
- Defines a new clang attr `RootSignature` which simply holds an
identifier to a corresponding root signature declaration as above
- Integrate the `HLSLRootSignatureParser` to construct the decl node in
`ParseMicrosoftAttributes` and then attach the parsed attr with an
identifier to the entry point function declaration.
- Defines the various required declaration methods
- Add testing that the declaration and reference attr are created
correctly, and some syntactical error tests.
It was previously proposed that we could have the root elements
reference be stored directly as an additional member of the attribute
and to not have a separate root signature decl. In contrast, by defining
them separately as this change proposes, we will allow a unique root
signature to have its own declaration in the AST tree. This allows us to
only construct a single root signature for all duplicate root signature
attributes. Having it located directly as a declaration might also prove
advantageous when we consider root signature libraries.
Resolves https://github.com/llvm/llvm-project/issues/119011
For a member function call like 'foo.bar<int>()', there are two
typo-correction points after parsing the dot. The first occurs in
ParseOptionalCXXScopeSpecifier, which tries to annotate the template
name following any scope specifiers.
If the template name bar is not found within 'foo', the parser was
previously instructed to drop any function templates found outside of
the scope. This was intended to prevent ambiguity in expressions like
'foo->bar < 7', as explained in commit 50a3cddd. However, it's
unnecessary to discard typo-corrected results that were strictly
resolved within the scope 'foo'.
We won't perform a second typo-correction in ParseUnqualifiedId after
the name being annotated.
Fixes https://github.com/llvm/llvm-project/issues/139226
The old codepath in GetFullTypeForDeclarator was under "if (not a class type)"
so that it failed to warn for class types. Move the diagnostic outside
of the "if" so that it warns in the proper situations.
Fixes#133380
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
This PR attempts to improve the diagnostics flag
`-Wtautological-overlap-compare` (#13473). I have added code to warn
about float-point literals and character literals. I have also changed
the warning message for the non-overlapping case to provide a more
correct hint to the user.
Fixes#13473.
This code was flagged by static analysis. It was a false positive but
the reason why this code is valid is subtle and folks refactoring this
code in the future could easily miss it.
Allows the __ptrauth qualifier to be applied to pointer sized integer types,
updates Sema to ensure trivially copyable, etc correctly handle address
discriminated integers, and updates codegen to perform authentication
around arithmetic on the types.
A bunch of uses of IsFunctionConversion don't use the third argument and
just make a dummy QualType to pass. This splits IsFunctionConversion
into 2 functions, one that just takes 2 arguments and does the check,
and one that does the actual conversion using the 3rd argument. Both
functions can be const and replace current uses appropriately.
We were failing to pass a required argument when emitting the
diagnostic, so the source range was being used in place of an index.
This caused a failed assertion due to the incorrect index.
Fixes#139266
We were trying to get type information out of an expression node which
contained errors. That causes the type of the expression to be
dependent, which the code was not expecting. Now we handle error
conditions with an early return.
Fixes#139073
This patch enhances Clang's diagnosis of an unknown attribute by
printing the attribute's namespace in the diagnostic text. e.g.,
```cpp
[[foo::nodiscard]] int f(); // warning: unknown attribute 'foo::nodiscard' ignored
```
The C++26 standard relocatable type traits has slightly different
semantics, so we introduced a new
``__builtin_is_cpp_trivially_relocatable``
when implementing trivial relocation in #127636.
However, having multiple relocatable traits would be confusing
in the long run, so we deprecate the old trait.
As discussed in #127636
`__builtin_is_cpp_trivially_relocatable` should be used instead.
When a builtin function is passed a pointer with a different
address space, clang creates an overloaded
builtin function but does not copy the host/device attribute. This
causes
error when the builtin is called by device functions
since CUDA/HIP relies on the host/device attribute to treat
a builtin function as callable on both host and device
sides.
Fixed by copying the host/device attribute of the original
builtin function to the created overloaded builtin function.
There are a few diagnostics that are incorrectly grouped under
`-Wc++20-compat` instead of `-Wpre-c++20-compat`.
I grepped for any remaining `-Wc++xy-compat` diagnostics, but they all
seem to actually be about compatibility with C++XY.
Fixes#138775.
This patch adds support in APINotes for annotating C++ user-defined
types with: `swift_attr("returned_as_unretained_by_default")`
This attribute allows to specify a default ownership convention for
return values of `SWIFT_SHARED_REFERENCE` c++ types. Specifically, it
marks all unannotated return values of this type as `unretained` (`+0`)
by default, unless explicitly overridden at the API level using
`swift_attr("returns_retained")` or `swift_attr("returns_unretained")`.
The corresponding Swift compiler support for this annotation enables
developers to suppress warnings about unannotated return ownership in
large codebases while maintaining safe and predictable ownership
semantics. By enabling this in APINotes, library authors can define this
behavior externally without needing to modify C++ source headers
directly.
### Example usage in APINotes:
```
- Name: RefCountedTypeWithDefaultConvention
SwiftImportAs: reference
SwiftDefaultOwnership: unretained
```
rdar://150764491
The C++26 standard relocatable type traits has slightly different
semantics, so we introduced a new
``__builtin_is_cpp_trivially_relocatable`` when implementing trivial
relocation in #127636.
However, having multiple relocatable traits would be confusing in the
long run, so we deprecate the old trait.
As discussed in #127636
`__builtin_is_cpp_trivially_relocatable` should be used instead.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
In C++, the type of an enumerator is the type of the enumeration,
whereas in C, the type of the enumerator is 'int'. The type of a comma
operator is the type of the right-hand operand, which means you can get
an implicit conversion with this code in C but not in C++:
```
enum E { Zero };
enum E foo() {
return ((void)0, Zero);
}
```
We were previously incorrectly diagnosing this code as being
incompatible with C++ because the type of the paren expression would be
'int' there, whereas in C++ the type is 'E'.
So now we handle the comma operator with special logic when analyzing
implicit conversions in C. When analyzing the left-hand operand of a
comma operator, we do not need to check for that operand causing an
implicit conversion for the entire comma expression. So we only check
for that case with the right-hand operand.
This addresses a concern brought up post-commit:
https://github.com/llvm/llvm-project/pull/137658#issuecomment-2854525259
Instead of eagerly populating the `clang::ModuleMap` when looking up a
module by name, this patch changes `HeaderSearch` to only load the
modules that are actually used.
This introduces `ModuleMap::findOrLoadModule` which will load modules
from parsed but not loaded module maps. This cannot be used anywhere
that the module loading code calls into as it can create infinite
recursion.
This currently just reparses module maps when looking up a module by
header. This is fine as redeclarations are allowed from the same file,
but future patches will also make looking up a module by header lazy.
This patch changes the shadow.m test to use explicitly built modules and
`#import`. This test and the shadow feature are very brittle and do not
work in general. The test relied on pcm files being left behind by prior
failing clang invocations that were then reused by the last invocation.
If you clean the cache then the last invocation will always fail. This
is because the input module map and the `-fmodule-map-file=` module map
are parsed in the same module scope, and `-fmodule-map-file=` is
forwarded to implicit module builds. That means you are guaranteed to
hit a module redeclaration error if the TU actually imports the module
it is trying to shadow.
This patch changes when we load A2's module map to after the `A` module
has been loaded, which sets the `IsFromModuleFile` bit on `A`. This
means that A2's `A` is skipped entirely instead of creating a shadow
module, and we get textual inclusion. It is possible to construct a case
where this would happen before this patch too.
An upcoming patch in this series will rework shadowing to work in the
general case, but that's only possible once header -> module lookup is
lazy too.
When forming an invalid function type, we were not diagnosing it if the
call was dependent.
However, we later rely on the function type to be sensible during
argument deduction.
We now diagnose anything that is not a potential function type, to avoid
constructing bogus call expressions.
Fixes#138657Fixes#115725Fixes#68852
This adds
- The parsing of `trivially_relocatable_if_eligible`,
`replaceable_if_eligible` keywords
- `__builtin_trivially_relocate`, implemented in terms of memmove. In
the future this should
- Add the appropriate start/end lifetime markers that llvm does not have
(`start_lifetime_as`)
- Add support for ptrauth when that's upstreamed
- the `__builtin_is_cpp_trivially_relocatable` and
`__builtin_is_replaceable` traits
Fixes#127609
We were testing the immediate DeclContext for found new and delete
operators, which is incorrect if the declarations are contained by a
transparent decl as can be induced with extern or export statements.
Check for struct members that are structs filled only with function
pointers by recursively examining it. Since the lamba
IsFunctionPointerOrForwardDecl cannot call itself directly, move it into
a helper function, EntirelyFunctionPointers, so it can be called from
the lambda.
Add test for composite function pointer structs getting automatically
randomized.
Add more tests for validating automatic randomization vs explicitly
annotated with "randomize_layout", and excluded with
"no_randomize_layout".
Reorder the "should we randomize?" "if" statement to check for
enablement before checking for Record details.
Fixes#138355
There are some limitations.
Because we only know which partial specialization to refer to when
instantiating, and because we can't instantiate the class before we
require a complete type, we can only use the partial specialization once
we have a complete class.
Similarly, because we don't know if a class is ever going to be
complete, we always warn on availability of the primary. Therefore, we
only warn for the partial specialization if we did not warn on the
primary.
I considered alternatives to address that second limitation:
- Delay warnings to the end of the TU
- Tracking where each availability attribute originally comes from.
However, both of these have drawbacks, and the use case is probably less
motivated than wanting to deprecate the use of a specific
specialization.
Fixes#44496
Transforming an expression to a potentially evaluated expression can
fail. If it does so, no longer attempt to make the type trait
expression, instead return an error expression. This ensures we don't
try to compute the dependence for an invalid type.
Fixes#138444
We were converting a CXXParenListInitExpr to a ParenListExpr in
TreeTransform.
However, ParenListExpr is typeless, so Clang could not rebuild the
correct initialization sequence in some contexts.
Fixes#72880
Thanks to changes to type compatibility rules via WG14 N3007, these
functions can now be called with a compatible type even within the same
TU, which makes the -Wvisibility diagnostic too chatty to have on by
default.
So in C23 mode, -Wvisibility will only diagnose an incomplete tag type
declared in a function prototype. If the tag is defined in the
prototype, the diagnostic is silenced.
