We already attempted to implement this (it was the intent of the paper),
in that parameters were never considered name-independent. However, we
failed to check that any previously found parameter declaration was also
name-independent.
Note that, as worded, the current resolution is insufficient (I wrote to
CWG with better wording), but there is some consensus on the design
outcome.
Fixes#136373
The "alternativeName" was introduced ~5 years ago in D82405, and at the
moment it has only one use, the one that the original change introduced.
OpenMP 6.0 spec has introduced different spellings of some directives,
but the "alternativeName" is not an adequate mechanism to implement it.
For those reasons remove the "alternativeName" member from both Clause
and Directive in DirectiveBase.td.
Since the alternativeName text appeared in a number of clang OpenMP
tests, implement `getOpenMPClauseNameForDiag` in SemaOpenMP.cpp to
preserve the text of the diagnostics.
This implements [LWG4113](https://cplusplus.github.io/LWG/issue411)
This is technically a breaking change, but it's a fix, and I think
anyone who relies on this today is in a world of hurt.
Fixes#118350
The previous code hits an assert inside the MSVC compiler version 16.8,
which is our minimum supported version. This patch looks on godbolt
like it avoids this crash, so submitting it to hopefully unbreak the
bot.
Brought up in a previous review as a TODO, we could be better about how
we highlight what hte previous clause was, and how to show that the
'device_type' is the one being targetted. This patch rewords the
diagnostics and updates a massive number of tests.
This drops the "and is incompatible with C++" phrasing from the
diagnostic unless -Wc++-compat is explicitly passed. This makes the
diagnostic less confusing when it is on by default rather than enabled
because of C++ compatibility concerns
Previously we just checked duplicates for a handful of clauses between
active device_type clauses. However, after looking into the
implementation for 'collapse', I discovered that duplicate device_type
identifiers with duplicate versions of htese clause are problematic.
This patch corrects this and now catches these conflicts.
Static analysis flagged that we use IFaceT in HandleExprPropertyRefExpr
without checking even though getInterfaceType() can return nullptr. The
comments make it clear the assumption is that we will always have an
interface, so we will document this via an assert.
Fixes: https://github.com/llvm/llvm-project/issues/134954
This changes the type compatibility rules so that it is permitted to
redefine tag types within the same TU so long as they are equivalent
definitions.
It is intentionally not being exposed as an extension in older C
language modes. GCC does not do so and the feature doesn't seem
compelling enough to warrant it.
We already diagnose when a jump bypasses initialization in C++ because
such code is ill-formed there. However, we were not using this to
diagnose those same jumps in C.
-Wjump-bypasses-init is grouped under -Wc++-compat and diagnoses this
situation as a compatibility issue with C++. This diagnostic is off by
default.
The diagnostic could perhaps be enabled by default for C, but due to the
design of jump diagnostic handling, it not a trivial task. For now,
we'll add the diagnostic as off-by-default so we get incremental
improvement, but a follow-up could try to refactor jump diagnostics so
we can enable this by default in C and have it as a C++ compatibility
diagnostic as well.
This adds a new diagnostic group, -Wc++-keyword, which is off by default
and grouped under -Wc++-compat. The diagnostic catches use of C++
keywords in C code.
This change additionally fixes an issue with -Wreserved-identifier not
diagnosing use of reserved identifiers in function parameter lists in a
function declaration which is not a definition.
Fixes https://github.com/llvm/llvm-project/issues/21898
As can be seen by the comment, this ends up being a construct that is
going to be quite a lot of work in the future to make sure we properly
identify the upperbound, lowerbound, and step. For now, we just treat
the 'loop' as container so that we can put the 'for' loop into it.
In the future, we'll have to teach the OpenACC dialect how to derive the
upperbound, lowerbound, and step from the cir.for loop. Additionally,
we'll probably have to add a few more options to it so that we can give
it the recipes it needs to determine these for random access iterators.
For Integer and Pointer values, these should already be known.
We made chained comparisons an error.
Fold-expressions over a comparison operator produce chained comparisons,
so we should be consistent there too.
We only emit the warning when instantiating the fold expression so as
not to warn on types with user-defined comparisons.
Partially addresses #129570
This patch adds templated `operator<<` for diagnostics that pass scoped
enums, saving people from `llvm::to_underlying()` clutter on the side of
emitting the diagnostic. This eliminates 80 out of 220 usages of
`llvm::to_underlying()` in Clang.
I also backported `std::is_scoped_enum_v` from C++23.
This adds a new diagnostic to warn about redeclaration of a tentative
definition in C. This is incompatible with C++, so the new diagnostic
group is under -Wc++-compat.
Post-commit review feedback on
https://github.com/llvm/llvm-project/pull/137166 raised a concern from
the Linux kernel about wanting to silence the new diagnostic when the
uninitialized object is a const member of a structure. These members can
be initialized later if the containing object is non-const, such as
through a call to memset, for example.
This splits the diagnostic groups into:
```
-Wc++-compat
-Wdefault-const-init
-Wdefault-const-init-field
-Wdefault-const-init-var
-Wdefault-const-init-unsafe
-Wdefault-const-init-field-unsafe
-Wdefault-const-init-var-unsafe
```
---------
Co-authored-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
The 'loop' construct has some limitations that are not particularly
clear on what can be in the for-loop. This patch adds some restriction
so that the increment can only be a addition or subtraction operation,
BUT starts allowing Itr = Itr +/- N forms.
Specifying only `space` in a `register` annotation means the compiler
should implicitly assign a register slot to the resource from the
provided virtual register space.
Closes#133346
This introduces three things related to intialization like:
char buf[3] = "foo";
where the array does not declare enough space for the null terminator
but otherwise can represent the array contents exactly.
1) An attribute named 'nonstring' which can be used to mark that a
field or variable is not intended to hold string data.
2) -Wunterminated-string-initialization, which is grouped under
-Wextra, and diagnoses the above construct unless the declaration
uses the 'nonstring' attribute.
3) -Wc++-unterminated-string-initialization, which is grouped under
-Wc++-compat, and diagnoses the above construct even if the
declaration uses the 'nonstring' attribute.
Fixes#137705
- Adds resource constructor that takes explicit binding for all resource
classes.
- Updates implementation of default resource constructor to initialize
resource handle to `poison`.
- Removes initialization of resource classes from Codegen.
- Initialization of `cbuffer` still needs to happen in `CGHLSLRuntime`
because it does not have a corresponding resource class type.
- Adds `ImplicitCastExpr` for builtin function calls. Sema adds these
automatically when a method of a template class is instantiated, but
some resource classes like `ByteAddressBuffer` are not templates so they
need to have this added explicitly.
Design proposal: llvm/wg-hlsl#197
Closes#134154
clang currently issues a warning when memset is used on a struct that
contains an address-discriminated pointer field, even though this is
entirely valid behavior.
For example:
```
struct S {
int * __ptrauth(1, 1, 100) p;
} s;
memset(&s, 0, sizeof(struct S));
```
Only allow the warning to be emitted in C++ mode to silence the warning.
rdar://142495870
This introduces a new diagnostic, -Wc++-hidden-decl, which is grouped
under -Wc++-compat, that diagnoses declarations which are valid in C but
invalid in C++ due to the type being at the wrong scope. e.g.,
```
struct S {
struct T {
int x;
} t;
};
struct T t; // Valid C, invalid C++
```
This is implementing the other half of #21898
This introduces a new diagnostic group to diagnose implicit casts from
int to an enumeration type. In C, this is valid, but it is not
compatible with C++.
Additionally, this moves the "implicit conversion from enum type to
different enum type" diagnostic from `-Wenum-conversion` to a new group
`-Wimplicit-enum-enum-cast`, which is a more accurate home for it.
`-Wimplicit-enum-enum-cast` is also under `-Wimplicit-int-enum-cast`, as
it is the same incompatibility (the enumeration on the right-hand is
promoted to `int`, so it's an int -> enum conversion).
Fixes#37027
