| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This renames some attribute list related functions, to make callers
think about whether they want to append or prepend to the list, instead
of defaulting to prepending which is often not the desired behaviour
(for the cases where it matters, sometimes we're just adding to an empty
list). Then it adjusts some of these calls to append where they were
previously prepending. This has the effect of making
`err_attributes_are_not_compatible` consistent in emitting diagnostics
as `<new-attr> and <existing-attr> are not compatible`, regardless of
the syntax used to apply the attributes.
|
|
Variadic argument for NVPTX has been support in
https://github.com/llvm/llvm-project/commit/486d00eca6b6ab470e8324b52cdf9f32023c1c9a
We can remove `CUDAAllowVariadicFunctions` option and its sema check. The CC1 option
`fcuda_allow_variadic_functions` is retained to not break the existing code building.
---------
Co-authored-by: Yuanke Luo <ykluo@birentech.com>
|
|
This adds an `operator<<` overload for `StreamingDiagnostic` that takes
an `APInt`/`APSInt` and formats it with default options, including
adding separators.
This is still an opt-in mechanism since all callers that want to use
this feature need to be changed from
```c++
Diag() << toString(MyInt, 10);
```
to
```c++
Diag() << MyInt;
```
This patch contains one example of a diagnostic making use of this.
|
|
We only display this diagnostic with large numbers, so add the
separators.
Not sure if `295'147'905'179'352'825'841` is much better than
`295147905179352825841` but I think it would be nice to have separators
in more diagnostics.
|
|
Clang would complain about conflicting types between a function
declaration and definition if the declaraion was marked with the
attribute but the definition wasn't. Do not treat this as an error. It
should only be necessary to mark the declaration with the attribute.
|
|
(#157667)
Previously, lambda init captures of structured bindings were incorrectly
classified as regular shadow warnings (shown with `-Wshadow`), while
regular parameter captures were correctly classified as
`uncaptured-local` warnings (shown only with `-Wshadow-all`). This
created inconsistent behavior:
```cpp
void foo1(std::pair<int, int> val) {
[val = std::move(val)](){}(); // No warning with -Wshadow (correct)
}
void foo2(std::pair<int, int> val) {
auto [a, b] = val;
[a = std::move(a)](){}(); // Warning with -Wshadow (incorrect)
}
```
The fix extends the existing lambda capture classification logic in
`CheckShadow()` to handle `BindingDecl` consistently with `VarDecl`,
ensuring both cases show no warnings with `-Wshadow` and
`uncaptured-local` warnings with `-Wshadow-all`.
Fixes #68605.
---------
Co-authored-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
|
|
A DependentTemplateSpecializationType (DTST) is basically just a
TemplateSpecializationType (TST) with a hardcoded DependentTemplateName
(DTN) as its TemplateName.
This removes the DTST and replaces all uses of it with a TST, removing a
lot of duplication in the implementation.
Technically the hardcoded DTN is an optimization for a most common case,
but the TST implementation is in better shape overall and with other
optimizations, so this patch ends up being an overall performance
positive:
<img width="1465" height="38" alt="image"
src="https://github.com/user-attachments/assets/084b0694-2839-427a-b664-eff400f780b5"
/>
A DTST also didn't allow a template name representing a DTN that was
substituted, such as from an alias template, while the TST does allow it
by the simple fact it can hold an arbitrary TemplateName, so this patch
also increases the amount of sugar retained, while still being faster
overall.
Example (from included test case):
```C++
template<template<class> class TT> using T1 = TT<int>;
template<class T> using T2 = T1<T::template X>;
```
Here we can now represent in the AST that `TT` was substituted for the
dependent template name `T::template X`.
|
|
different modules
See the attached example for motivation. Although it is not sure how
should we treat the modules ownership of the implicit instantiations,
it makes no sense to diagnose redeclaration of implicit instantiations
in different modules.
|
|
Adds support for unbounded resource arrays declared at a global scope. Local unbounded resource array variables or incomplete resource arrays as function arguments are not going be supported in HLSL in Clang. See:
- https://github.com/microsoft/hlsl-specs/issues/141
- https://github.com/llvm/wg-hlsl/pull/298
Closes #145427
|
|
(#155965)
Fix an error in the logic meant to handle a redeclaration such as:
```C++
struct A {
struct __attribute__((foo)) A *ptr;
};
```
In the declaration of ptr, we must introduce a new redeclaration of A in
order for it to carry the new attribute. This is a redeclaration of the
existing A, but it is only lexically contained in A, still semantically
belonging to the TU. This is the same deal as happens with friend
declarations, and the logic used to handle that is reused here.
But this was going haywire with a class indirectly nested within a class
of the same name.
The fix limits this logic to only apply when the tag use is just a
simple reference.
Since this regression was never released, there are no release notes.
Fixes #155936
|
|
The regression was introduced in #155313
Since this regression was never released, there are no release notes.
Fixes #155794
|
|
|
|
This reintroduces `Type.h`, having earlier been renamed to `TypeBase.h`,
as a redirection to `TypeBase.h`, and redirects most users to include
the former instead.
This is a preparatory patch for being able to provide inline definitions
for `Type` methods which would otherwise cause a circular dependency
with `Decl{,CXX}.h`.
Doing these operations into their own NFC patch helps the git rename
detection logic work, preserving the history.
This patch makes clang just a little slower to build (~0.17%), just
because it makes more code indirectly include `DeclCXX.h`.
|
|
This is a preparatory patch, to be able to provide inline definitions
for `Type` functions which depend on `Decl{,CXX}.h`. As the latter also
depends on `Type.h`, this would not be possible without some
reorganizing.
Splitting this rename into its own patch allows git to track this as a
rename, and preserve all git history, and not force any code
reformatting.
A later NFC patch will reintroduce `Type.h` as redirection to
`TypeBase.h`, rewriting most places back to directly including `Type.h`
instead of `TypeBase.h`, leaving only a handful of places where this is
necessary.
Then yet a later patch will exploit this by making more stuff inline.
|
|
compatible (#154490)
A number of builtins report some variation of "this type is compatibile
with some bitwise equivalent operation", but this is not true for
address discriminated values. We had address a number of cases, but not
all of them. This PR corrects the remaining builtins.
Fixes #154394
|
|
TagDecls (#155463)
And make use of those.
These changes are split from prior PR #155028, in order to decrease the
size of that PR and facilitate review.
|
|
This changes a bunch of places which use getAs<TagType>, including
derived types, just to obtain the tag definition.
This is preparation for #155028, offloading all the changes that PR used
to introduce which don't depend on any new helpers.
|
|
(#140282)
This patch is part of the upstreaming effort for supporting SYCL
language front end.
It makes the following changes:
1. Adds sycl_external attribute for functions with external linkage,
which is intended for use to implement the SYCL_EXTERNAL macro as
specified by the SYCL 2020 specification
2. Adds checks to avoid emitting device code when sycl_external and
sycl_kernel_entry_point attributes are not enabled
3. Fixes test failures caused by the above changes
This patch is missing diagnostics for the following diagnostics listed
in the SYCL 2020 specification's section 5.10.1, which will be addressed
in a subsequent PR:
Functions that are declared using SYCL_EXTERNAL have the following
additional restrictions beyond those imposed on other device functions:
1. If the SYCL backend does not support the generic address space then
the function cannot use raw pointers as parameter or return types.
Explicit pointer classes must be used instead;
2. The function cannot call group::parallel_for_work_item;
3. The function cannot be called from a parallel_for_work_group scope.
In addition to that, the subsequent PR will also implement diagnostics
for inline functions including virtual functions defined as inline.
---------
Co-authored-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
|
|
context" (#154458)
The immediate evaluation context needs the lambda scope info to
propagate some flags, however that LSI was removed in
ActOnFinishFunctionBody which happened before rebuilding a lambda
expression.
The last attempt destroyed LSI at the end of the block scope, after
which we still need it in DiagnoseShadowingLambdaDecls.
This also converts the wrapper function to default arguments as a
drive-by fix, as well as does some cleanup.
Fixes https://github.com/llvm/llvm-project/issues/145776
|
|
The import and include problem is a long-standing issue with the use of
C++20 modules. This patch tried to improve this by skipping parsing
class and functions if their declaration is already defined in modules.
The scale of the patch itself is small as the patch reuses previous
optimization. Maybe we can skip parsing other declarations in the
future. But the patch itself should be good.
|
|
comma in initializer lists" (#154369)
Revert llvm/llvm-project#154018 changes due to excessive _false
positives_. The warning caused multiple benign reports in large
codebases (e.g. _Linux kernel_, _Fuchsia_, _tcpdump_). Since many of
these concatenations are intentional and follow project style rules, the
diagnostic introduced more false positives than value. This will be
revisited as a potential `clang-tidy` check instead.
|
|
(#154382)
Revert due to breakage as reported in
https://github.com/llvm/llvm-project/pull/154106#discussion_r2285824084
Reverts llvm/llvm-project#154106
|
|
The immediate evaluation context needs the lambda scope info to
propagate some flags, however that LSI was removed in
ActOnFinishFunctionBody which happened before rebuilding a lambda
expression.
This also converts the wrapper function to default arguments as a
drive-by fix.
Fixes https://github.com/llvm/llvm-project/issues/145776
|
|
initializer lists (#154018)
Fixes #153745
---
This PR addresses a limitation in `-Wstring-concatenation`, where only
the first missing comma in an initializer list was diagnosed.
|
|
ActOnEnumConstant (#143754)
Static analysis flagged that we were not checking the return value of
DiagnoseClassNameShadow when we did so everywhere else. Modifying this
case to match how other places uses it makes sense and does not change
behavior. Likely if this check fails later actions will fail as well but
it is more correct to exit early.
|
|
This modifies InjectAnonymousStructOrUnionMembers to inject an
IndirectFieldDecl and mark it invalid even if its name conflicts with
another name in the scope.
This resolves a crash on a further diagnostic
diag::err_multiple_mem_union_initialization which via
findDefaultInitializer relies on these declarations being present.
Fixes #149985
|
|
Close https://github.com/llvm/llvm-project/issues/138558
The compiler failed to understand the redeclaration-relationship when
performing checks when MergeFunctionDecl. This seemed to be a complex
circular problem (how can we know the redeclaration relationship before
performing merging?). But the fix seems to be easy and safe. It is fine
to only perform the check only if the using decl is a local decl.
|
|
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes #136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
|
|
specializations. (#151815)
Addressing
https://github.com/llvm/llvm-project/pull/150003#discussion_r2249169463
|
|
This was added purely for the needs of LLDB. However, starting with
https://github.com/llvm/llvm-project/pull/151355 and
https://github.com/llvm/llvm-project/pull/148877 we no longer create
literal AsmLabels in LLDB either. So this is unused and we can get rid
of it.
In the near future LLDB will want to add special support for mangling
`AsmLabel`s (specifically
https://github.com/llvm/llvm-project/pull/149827).
|
|
|
|
From d8ca85a184c0fb511fe6483c4c24e48b5b1eb07a
|
|
The Loc param to these functions was weird and not always set in error
cases. It wasn't reliable to use.
This was almost entirely unused inside of clang and the one call site
that used the returned source location doesn't make a difference in
practice.
|
|
style. (#151405)
Previously, the `sycl_kernel_entry_point` attribute could be specified
using either the GNU or C++11 spelling styles. Future SYCL attributes
are expected to support only the C++11 spelling style, so support for
the GNU style is being removed.
In order to ensure consistent presentation of the attribute in
diagnostic messages, diagnostics specific to this attribute now require
the attribute to be provided as an argument. This delegates formatting
of the attribute name to the diagnostic engine.
As an additional nicety, "the" is added to some diagnostic messages so
that they read more like proper sentences.
|
|
The Cygwin target is generally very similar to the MinGW target. The
default auto-import behavior, the default calling convention, the
`.dll.a` import library extension, the `__GXX_TYPEINFO_EQUALITY_INLINE`
pre-define by `g++`, and the long double configuration.
Co-authored-by: Mateusz Mikuła <oss@mateuszmikula.dev>
|
|
specializations (#150003)
This patch fixes incorrect behavior in Clang where [[noreturn]] (either
spelled or inferred) was being inherited by explicit specializations of
function templates or member function templates, even when those
specializations returned normally.
Follow up on https://github.com/llvm/llvm-project/pull/145166
|
|
This fixes an issue introduced by
https://github.com/llvm/llvm-project/pull/84150, where failing to pop
compound scope, function scope info, and decl context after a failed
statement could lead to an inconsistent internal state.
|
|
Forward declarations can still have useful API notes applied to them.
When the use of the tag is not a definition, apply the API notes
immediately.
Fixes rdar://156288588.
|
|
getAsmLabel() already returns Expr *.
|
|
The underlying type of an enumeration is the non-atomic, unqualified
version of the specified type. Clang was rejecting such enumerations,
with a hard error, but now has the ability to downgrade the error into a
warning. Additionally, we diagnose (as a warning) dropping other
qualifiers. _Atomic is special given that an atomic type need not have
the same size as its non-atomic counterpart, and that the C++ version
of <stdatomic.h> defines _Atomic to std::atomic for easing cross-
language atomic use and std::atomic is an invalid enum base in C++.
(Note: we expose _Atomic in C++ even without including
<stdatomic,h>.)
Fixes #147736
|
|
BitWidth is already of Expr *.
|
|
Revival of https://github.com/llvm/llvm-project/pull/146247 which got
reverted for broken test.
Now that https://github.com/llvm/llvm-project/pull/146461 is merged to
allow `extern "C++"` for main, we can merge this change.
|
|
module (#146461)
Remove the prior warning for attaching extern "C++" to main.
|
|
This reverts commit 473769ec9b2f860813229eb449fb4298dfc7ff94.
It breaks test in libc++
See https://github.com/llvm/llvm-project/pull/146247
|
|
Since dllexport/dllimport annotations don't propagate the same way as
visibility, the unique object duplication warning needs to check both
the object in question and its containing class. Previously, we
restricted this check to static data members, but it applies to all
objects inside a class, including functions. Not checking functions
leads to false positives, so remove that restriction.
|
|
Close https://github.com/llvm/llvm-project/issues/146229
As the issue said, main shouldn't be in any modules.
new diagnostic output:
```
/my/code/directory/main.cpp:3:1: warning: 'main' should not be attached to a named module; consider adding C++ language linkage [-Wmain]
3 | int main() {
| ^
| extern "C++"
1 warning generated.
```
|
|
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
|
|
SourceLocation (#145711)
Introduce a type alias for the commonly used `std::pair<FileID,
unsigned>` to improve code readability, and make it easier for future
updates (64-bit source locations).
|
|
- **Reapply "[HLSL][SPIRV] Add vk::constant_id attribute." (#144812)**
- **Fix memory leak.**
|
|
Reverts llvm/llvm-project#143544
|
