When passing arguments with `__fastcall` or `__vectorcall` in 32-bit MSVC, the following arguments have chance to be passed by register if the current one failed. `__regcall` from ICC is on the contrary: https://godbolt.org/z/4MPbzhaMG
All the three calling conversions are not supported in GCC.
Fixes: #57737
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D133920
Implement suggested fix for [[ https://cplusplus.github.io/CWG/issues/2628.html | DR2628. ]] Couldn't update the DR docs because there hasn't been a DR index since it was filed, but the tests still run in CI.
Note: I only transfer the constructor constraints, not the struct constraints. I think that's OK because the struct constraints are the same
for all constructors so they don't affect the overload resolution, and if they deduce to something that doesn't pass the constraints
we catch it anyway. So (hopefully) that should be more efficient without sacrificing correctness.
Closes:
https://github.com/llvm/llvm-project/issues/57646https://github.com/llvm/llvm-project/issues/43829
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D134145
We would diagnose use of `long long` as an extension in C89 and C++98
modes when the user spelled the type `long long` or used the `LL`
literal suffix, but failed to diagnose when the literal had no suffix
but required a `long long` to represent the value.
We change the template specialization of builtin templates to
behave like aliases.
Though unlike real alias templates, these might still produce a canonical
TemplateSpecializationType when some important argument is dependent.
For example, we can't do anything about make_integer_seq when the
count is dependent, or a type_pack_element when the index is dependent.
We change type deduction to not try to deduce canonical TSTs of
builtin templates.
We also change those buitin templates to produce substitution sugar,
just like a real instantiation would, making the resulting type correctly
represent the template arguments used to specialize the underlying template.
And make_integer_seq will now produce a TST for the specialization
of it's first argument, which we use as the underlying type of
the builtin alias.
When performing member access on the resulting type, it's now
possible to map from a Subst* node to the template argument
as-written used in a regular fashion, without special casing.
And this fixes a bunch of bugs with relation to these builtin
templates factoring into deduction.
Fixes GH42102 and GH51928.
Depends on D133261
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133262
This continues D111283 by extending the getCommonSugaredType
implementation to also merge non-canonical type nodes.
We merge these nodes by going up starting from the canonical
node, calculating their merged properties on the way.
If we reach a pair that is too different, or which we could not
otherwise unify, we bail out and don't try to keep going on to
the next pair, in effect striping out all the remaining top-level
sugar nodes. This avoids mismatching 'companion' nodes, such as
ElaboratedType, so that they don't end up elaborating some other
unrelated thing.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D130308
While investigating something else, I discovered that a prototypeless
function with 'overloadable' was having the attribute left on the
declaration, which caused 'ambiguous' call errors later on. This lead to
some confusion. This patch removes the 'overloadable' attribute from
the declaration and leaves it as prototypeless, instead of trying to
make it variadic.
Sometimes we make changes to the compiler that we expect may cause
disruption for users. For example, we may strengthen a warning to
default to be an error, or fix an accepts-invalid bug that's been
around for a long time, etc which may cause previously accepted code to
now be rejected. Rather than hope users discover that information by
reading all of the release notes, it's better that we call these out in
one location at the top of the release notes.
Based on feedback collected in the discussion at:
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/
Differential Revision: https://reviews.llvm.org/D133771
The original proposal was seen in Apr 2019 and we accidentally used
that date (201904L) as the feature testing value. However, WG14 N2408
was adopted at the Oct 2019 meeting and so that's the correct date for
the feature testing macro. The committee draft for C2x shows 201910L
for this value, so this changes brings us in line with the standard.
The original proposal was adopted in Apr 2019, but was subsequently
updated by WG14 N2662 in June 2021. We already supported the attribute
on a label and it behaved as expected, but we had not bumped the
feature test value.
The original proposal was adopted in Apr 2019 and so the previous value
was 201904L. However, a subsequent proposal (N2448) was adopted to add
an optional message argument to the attribute. We already support that
functionality, but had not bumped the feature test value.
If the declaration of an identifier has block scope, and the identifier has
external or internal linkage, the declaration shall have no initializer for
the identifier.
Clang now gives a more suitable diagnosis for this case.
Fixes https://github.com/llvm/llvm-project/issues/57478
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D133088
The diagnostics here are correct, but the note is really silly. It
talks about reinterpret_cast in C code. So rewording it for c mode by
using another %select{}.
```
int array[(long)(char *)0];
```
previous note:
```
cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
```
reworded note:
```
this conversion is not allowed in a constant expression
```
Differential Revision: https://reviews.llvm.org/D133194
Clang has support of virtual file system for the purpose of testing, but
treatment of config files did not use it. This change enables VFS in it
as well.
Differential Revision: https://reviews.llvm.org/D132867
Clang has support of virtual file system for the purpose of testing, but
treatment of config files did not use it. This change enables VFS in it
as well.
Differential Revision: https://reviews.llvm.org/D132867
This option can be used to enable Control Flow Guard checks and
generation of address-taken function table. They are equivalent to
`/guard:cf` and `/guard:cf,nochecks` in clang-cl. Passing this flag to
the Clang driver will also pass `--guard-cf` to the MinGW linker.
This feature is disabled by default. The option `-mguard=none` is also
available to explicitly disable this feature.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D132810
Avoid __builtin_assume_aligned crash when the 1st arg is array type (or
string literal).
Fixes Issue #57169
Differential Revision: https://reviews.llvm.org/D133202
Per the documentation, these restrictions were intended to apply to textual headers but previously this didn't work because we decided there was no requesting module when the `#include` was in a textual header.
A `-cc1` flag is provided to restore the old behavior for transitionary purposes.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132779
This implements setting the equivalent of `-fcrash-diagnostics-dir`
through the environment variable `CLANG_CRASH_DIAGNOSTICS_DIR`.
If present, the flag still takes precedence.
This helps integration with test frameworks and pipelines.
With this feature, we change the libcxx bootstrapping build
pipeline to produce clang crash reproducers as artifacts.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133082
I discovered this additional bug at the end of working on D132906
In Sema::CheckCompletedCXXClass(...) uses a lambda CheckForDefaultedFunction to
verify each CXXMethodDecl holds to the expected invariants before passing them
on to CheckForDefaultedFunction.
It is currently missing a check that it is not deleted, this adds that check and
a test that crashed without this check.
This fixes: https://github.com/llvm/llvm-project/issues/57516
Differential Revision: https://reviews.llvm.org/D133177
The method is now wrapped by clang_getNonReferenceType.
A declaration for clang_getNonReferenceType was added to clang-c/Index.h
to expose it to user of the library.
An implementation for clang_getNonReferenceType was introduced in
CXType.cpp, wrapping the equivalent method of the underlying QualType of
a CXType.
An export symbol for the new function was added to libclang.map under
the LLVM_16 version entry.
A test was added to LibclangTest.cpp that tests the removal of
ref-qualifiers for some CXTypes.
The release-notes for the clang project was updated to include a
notification of the new addition under the "libclang" section.
Differential Revision: https://reviews.llvm.org/D133195
Previously if you specified no_sanitize("known_sanitizer") on a global you
would yield a misleading error "'no_sanitize' attribute only applies to
functions and methods", but no_sanitize("unknown") would simply be a warning,
"unknown sanitizer 'unknown' ignored". This changes the former to a warning
"'no_sanitize' attribute argument not supported for globals: known_sanitizer".
Differential Revision: https://reviews.llvm.org/D133117
The main focus of this patch is to make ArgType::matchesType check for
possible default parameter promotions when the argType is not a pointer.
If so, no warning will be given for `int`, `unsigned int` types as
corresponding arguments to %hhd and %hd. However, the usage of %hhd
corresponding to short is relatively rare, and it is more likely to be a
misuse. This patch keeps the original behavior of clang like this as
much as possible, while making it more convenient to consider the
default arguments promotion.
Fixes https://github.com/llvm/llvm-project/issues/57102
Reviewed By: aaron.ballman, nickdesaulniers, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D132568
https://reviews.llvm.org/D131255 (82afc9b169)
began warning about conversion causing data loss for a single-bit
bit-field. However, after landing the changes, there were reports about
significant false positives from some code bases.
This alters the approach taken in that patch by introducing a new
warning group (-Wsingle-bit-bitfield-constant-conversion) which is
grouped under -Wbitfield-constant-conversion to allow users to
selectively disable the single-bit warning without losing the other
constant conversion warnings.
Differential Revision: https://reviews.llvm.org/D132851
In Sema::CheckCompletedCXXClass(...) It used a lambda CheckForDefaultedFunction
the CXXMethodDecl passed to CheckForDefaultedFunction may not be a special
member function and so before attempting to apply functions that only apply to
special member functions it needs to check. It fails to do this before calling
DefineDefaultedFunction(...). This PR adds that check and test to verify we no
longer crash.
This fixes https://github.com/llvm/llvm-project/issues/57431
Differential Revision: https://reviews.llvm.org/D132906
When checking parameter packs for expansion, instead of basing the diagnostic for
length mismatch for outer parameters only on the known number of expansions,
we should also analyze SubstTemplateTypeParmPackType and SubstNonTypeTemplateParmPackExpr
for unexpanded packs, so we can emit a diagnostic pointing to a concrete
outer parameter.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D128095
Summary:
Some of code in the patch are contributed by David Tenty.
1. We currently only check driver Wl options and don't check for the plain -b, -Xlinker or other options which get passed through to the linker when we decide whether to run llvm-nm --export-symbols, so we may run it in situations where we wouldn't if the user had used the equivalent -Wl, prefixed options. If we run the export list utility when the user has specified an export list, we could export more symbols than they intended.
2. Add a new functionality to allow redirecting the stdin, stdout, stderr of individual Jobs, if redirects are set for the Job use them, otherwise fall back to the global Compilation redirects if any.
Reviewers: David Tenty, Fangrui Song, Steven Wan
Differential Revision: https://reviews.llvm.org/D119147
To have finer control of IR uwtable attribute generation. For target code generation,
IR nounwind and uwtable may have some interaction. However, for frontend, there are
no semantic interactions so the this new `nouwtable` is marked "SimpleHandler = 1".
Differential Revision: https://reviews.llvm.org/D132592
The method is now wrapped by clang_getUnqualifiedType.
A declaration for clang_getUnqualifiedType was added to
clang-c/Index.h to expose it to user of the library.
An implementation for clang_getUnqualifiedType was introduced in
CXType.cpp that wraps the equivalent method of the underlying
QualType of a CXType.
An export symbol was added to libclang.map under the new version entry
LLVM_16.
A test was added to LibclangTest.cpp that tests the removal of
qualifiers for some CXTypes.
Differential Revision: https://reviews.llvm.org/D132749
Control Flow Guard is only supported on Windows target, therefore there
is no point to make it an accepted attribute for other targets.
Reviewed By: rnk, aaron.ballman
Differential Revision: https://reviews.llvm.org/D132661
In Sema::LookupTemplateName(...) seeks to assert that the ObjectType is complete
or being defined. If the type is incomplete it will attempt to unconditionally
cast it to a TagType and not all incomplete types are a TagType. For example the
type could be void or it could be an IncompleteArray.
This change adds an additional check to confirm it is a TagType before attempting
to check if it is incomplete or being defined
Differential Revision: https://reviews.llvm.org/D132712
Clang crashes when encountering an `if consteval` statement.
This is the minimum fix not to crash.
The fix is consistent with the current behavior of if constexpr,
which does generate coverage data for the discarded branches.
This is of course not correct and a better solution is
needed for both if constexpr and if consteval.
See https://github.com/llvm/llvm-project/issues/54419.
Fixes#57377
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132723
The patch diagnoses an identifier as a future keyword if it exists in a
future language mode, such as:
int restrict;
in C modes earlier than C99. We now give a warning to the user that
such an identifier is a future keyword. Handles keywords from C as well
as C++.
Differential Revision: https://reviews.llvm.org/D131683
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
To support using Control Flow Guard with mingw-w64, Clang needs to
accept `__declspec(guard(nocf))` also for the GNU target. Since mingw
has `#define __declspec(a) __attribute__((a))` as built-in, the simplest
solution is to accept `__attribute__((guard(nocf)))` to be compatible with
MSVC and Clang's msvc target.
As a side effect, this also adds `[[clang::guard(nocf)]]` for C++.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132302
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
Since the patch missed release 15.x and will be included in release 16.x. Also, simplify related tests.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132414
As proposed in D126215 (ffe7950ebc),
I'm dropping the `-analyzer-store` and
`-analyzer-opt-analyze-nested-blocks` clang frontend flags.
I'm also dropping the corresponding commandline handlers of `scanbuild`.
This behavior is planned to be part of `clang-16`.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D132289
This reverts commit d483730d8c.
This allegedly breaks a significant part of facebooks internal build.
Reverting while we wait for them to provide a reproducer of this from
@wlei.
The patch mainly focuses on the no warnings for -Wtautological-compare.
It work fine for the positive numbers but doesn't for the negative
numbers. This is because the warning explicitly checks for an
IntegerLiteral AST node, but -1 is represented by a UnaryOperator with
an IntegerLiteral sub-Expr.
Fixes#42918
Differential Revision: https://reviews.llvm.org/D130510
Instead of complaining about default initialization, tell users that
constexpr variables need to be initialized by a constant expression.
Differential Revision: https://reviews.llvm.org/D131662
The previous implementation translated from names like sifive-7-series
to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32
and sifive-7-rv64 to be valid CPU names. As those are not real
CPUs it doesn't make sense to accept them in -mcpu.
This patch does away with the translation and adds sifive-7-series
directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64.
sifive-7-series is only allowed in -mtune.
I've also added "rocket" to RISCV.td but have not removed rocket-rv32
or rocket-rv64.
To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc,
I've added a Feature32Bit to all rv32 CPUs. And made it an error to
have an rv32 triple without Feature32Bit. sifive-7-series and rocket
do not have Feature32Bit or Feature64Bit set so the user would need
to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to
avoid the error.
SiFive no longer names their newer products with 3, 5, or 7 series.
Instead we have p200 series, x200 series, p500 series, and p600 series.
Following the previous behavior would require a sifive-p500-rv32 and
sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There
is currently no p500 product, but it could start getting confusing if
there was in the future.
I'm open to hearing alternatives for how to achieve my main goal
of removing sifive-7-rv32/rv64 as a CPU name.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D131708
We deferred the evaluation of dependent immediate invocations in https://reviews.llvm.org/D119375 until instantiation.
We should also not consider them referenced from a non-consteval context.
Fixes: https://github.com/llvm/llvm-project/issues/55601
```
template<typename T>
class Bar {
consteval static T x() { return 5; }
public:
Bar() : a(x()) {}
private:
int a;
};
Bar<int> g();
```
Is now accepted by clang. Previously it errored with: `cannot take address of consteval function 'x' outside of an immediate invocation Bar() : a(x()) {}`
Differential Revision: https://reviews.llvm.org/D132031
This reverts commit 258c3aee54.
This should fix the libc++ issue that caused the revert, by re-designing
slightly how we determined when we should evaluate the constraints.
Additionally, many of the other components to the original patch (the
NFC parts) were committed separately to shrink the size of this patch
for review.
Differential Revision: https://reviews.llvm.org/D126907
When expanding undeclared function parameters, we should initialize
the original number of expansions, if known, before trying to expand
them, otherwise a length mismatch with an outer pack might not be
diagnosed.
Fixes PR56094.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D131802
DR692 handles two cases: pack expansion (for class/var template) and function parameter pack. The former needs DR1432 as a fix, and the latter needs DR1395 as a fix. However, DR1432 has not yet made a wording change. so I made a tentative fix for DR1432 with the same spirit as DR1395.
Reviewed By: aaron.ballman, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128745
Before this patch type traits are checked in Parser, so use type traits
directly did not cause assertion faults. However if type traits are initialized
from a template, we didn't perform arity checks before evaluating. This
patch moves arity checks from Parser to Sema, and performing arity
checks in Sema actions, so type traits get checked corretly.
Crash input:
```
template<class... Ts> bool b = __is_constructible(Ts...);
bool x = b<>;
```
After this patch:
```
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:5:32: error: type trait requires 1 or more arguments; have 0 arguments
template<class... Ts> bool b = __is_constructible(Ts...);
^~~~~~~~~~~~~~~~~~
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:6:10: note: in instantiation of variable template specialization 'b<>' requested here
bool x = b<>;
^
1 error generated.
```
See https://godbolt.org/z/q39W78hsK.
Fixes https://github.com/llvm/llvm-project/issues/57008
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131423
Followup patch for D128083
Previously, using a non-consteval constructor from an consteval constructor would code generates the consteval constructor.
Example
```
template <typename T>
struct S {
T i;
consteval S() = default;
};
struct Foo {
Foo() {}
};
void func() {
S<Foo> three; // incorrectly accepted by clang.
}
```
This happened because clang erroneously disregards `consteval` specifier for a `consteval explicitly defaulted special member functions in a class template` if it has dependent data members without a `consteval default constructor`.
According to
```
C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358):
If the instantiated template specialization of a constexpr function
template or member function of a class template would fail to satisfy
the requirements for a constexpr function or constexpr constructor, that
specialization is still a constexpr function or constexpr constructor,
even though a call to such a function cannot appear in a constant
expression.
```
Therefore the `consteval defaulted constructor of a class template` should be considered `consteval` even if the data members' default constructors are not consteval.
Keeping this constructor `consteval` allows complaining while processing the call to data member constructors.
(Same applies for other special member functions).
This works fine even when we have more than one default constructors since we process the constructors after the templates are instantiated.
This does not address initialization issues raised in
[2602](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2602) and compiler divergence seen in https://godbolt.org/z/va9EMvvMe
Fixes: https://github.com/llvm/llvm-project/issues/51593
Differential Revision: https://reviews.llvm.org/D131479
Clang currently crashes when lowering a consteval list initialization
of a temporary. This is partially working around an issue in the
template instantiation code (TreeTransform::TransformCXXTemporaryObjectExpr())
that does not yet know how to handle list initialization of temporaries
in all cases. However, it's also helping reduce fragility by ensuring
we always have a valid QualType when trying to emit a constant
expression during IR generation.
Fixes#55871
Differential Revision: https://reviews.llvm.org/D131194
For failed static assertions, try to take the expression apart and print
useful information about why it failed. In particular, look at binary
operators and print the compile-time evaluated value of the LHS/RHS.
Differential Revision: https://reviews.llvm.org/D130894
When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c07240 (and later extended in
b636875196).
When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.
The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.
The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.
This differs from GCC, which rejects PCH files if the defines differ
at all.
When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).
However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.
Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.
This fixes https://github.com/lhmouse/mcfgthread/issues/63.
Differential Revision: https://reviews.llvm.org/D126676
Implicitly converting between incompatible function pointers in C is
currently a default-on warning (it is an error in C++). However, this
is very poor security posture. A mismatch in parameters or return
types, or a mismatch in calling conventions, etc can lead to
exploitable security vulnerabilities. Rather than allow this unsafe
practice with a warning, this patch strengthens the warning to be an
error (while still allowing users the ability to disable the error or
the warning entirely to ease migration). Users should either ensure the
signatures are correctly compatible or they should use an explicit cast
if they believe that's more reasonable.
Differential Revision: https://reviews.llvm.org/D131351
A one-bit signed bit-field can only hold the values 0 and -1; this
corrects the diagnostic behavior accordingly.
Fixes#53253
Differential Revision: https://reviews.llvm.org/D131255
In D130058 we diagnose the undefined behavior of setting the value outside the
range of the enumerations values for an enum without a fixed underlying type.
Based on feedback we will provide users to the ability to downgrade this
diagnostic to a waring to allow for a transition period. We expect to turn this
diagnostic to an error in the next release.
Differential Revision: https://reviews.llvm.org/D131307
Consider:
A == 5 && A != 5
IfA is 5, the old collectConjunctionTerms() would call itself again for
the LHS (which it ignores), then the RHS (which it also ignores) and
then just return without ever adding anything to the Terms array.
Differential Revision: https://reviews.llvm.org/D131070
Close#56885: WG14 N2630 added %b to fprintf/fscanf and recommended %B for
fprintf. This patch teaches -Wformat %b for the printf/scanf family of functions
and %B for the printf family of functions.
glibc 2.35 and latest Android bionic added %b/%B printf support. From
https://www.openwall.com/lists/libc-coord/2022/07/ no scanf support is available
yet.
Like GCC, we don't test library support.
GCC 12 -Wformat -pedantic emits a warning:
> warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=]
The behavior is not ported.
Note: `freebsd_kernel_printf` uses %b differently.
Reviewed By: aaron.ballman, dim, enh
Differential Revision: https://reviews.llvm.org/D131057
This patch enhances clang's ability to check compile-time determinable
string literals as format strings, and can give FixIt hints at literals
(unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805
mentiond two compile-time string cases. And this patch partially fixes
one.
```
constexpr const char* foo() {
return "%s %d";
}
int main() {
printf(foo(), "abc", "def");
return 0;
}
```
This patch enables clang check format string for this:
```
<source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat]
printf(foo(), "abc", "def");
~~~~~ ^~~~~
<source>:2:42: note: format string is defined here
constexpr const char *foo() { return "%s %d"; }
^~
%s
1 warning generated.
```
Reviewed By: aaron.ballman
Signed-off-by: YingChi Long <me@inclyc.cn>
Differential Revision: https://reviews.llvm.org/D130906
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
We already correctly rejected:
typedef __attribute__((vector_size(16))) _BitInt(4) Ty;
but we would assert with:
typedef __attribute__((ext_vector_type(4))) _BitInt(4) Ty;
Now we issue the same error in both cases.
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
VisitCXXConstructExpr() will later do something similar, but for large
arrays, we should try to do it once an not for every element.
Fixes#56774
Differential Revision: https://reviews.llvm.org/D130791
We didn't check that a destructor's name matches the directly enclosing class if the class was dependent.
I enabled the check we already had for non-dependent types, which seems to work. Added appropriate tests.
Fixes GitHub issue #56772
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D130936
This reverts commit 0cc3c184c7.
The changes did not account for templated code where one instantiation
may trigger the diagnostic but other instantiations will not, as in:
```
template <int I, class T>
void foo(int x) {
bool b1 = (x & sizeof(T)) == 8;
bool b2 = (x & I) == 8;
bool b3 = (x & 4) == 8;
}
void run(int x) {
foo<4, int>(8);
}
```
This is a follow-up to D130058 to fix how we handle the Max value we obtain from
getValueRange(...) in IntExprEvaluator::VisitCastExpr(...) which in the case of
an enum that contains an enumerator with the max integer value will overflow by
one.
The fix is to decrement the value of Max and use slt and ult for comparison Vs
sle and ule.`
Differential Revision: https://reviews.llvm.org/D130811
C99 6.7.4p2 clarifies that a function specifier can only be used in the
declaration of a function. _Noreturn is a function specifier, so it is
a constraint violation to write it on a structure or union field, but
we missed that case.
Fixes#56800
DR2338 clarified that it was undefined behavior to set the value outside the
range of the enumerations values for an enum without a fixed underlying type.
We should diagnose this with a constant expression context.
Differential Revision: https://reviews.llvm.org/D130058
The patch mainly focuses on the lack of warnings for
-Wtautological-compare. It works fine for positive numbers but doesn't
for negative numbers. This is because the warning explicitly checks for
an IntegerLiteral AST node, but -1 is represented by a UnaryOperator
with an IntegerLiteral sub-Expr.
For the below code we have warnings:
if (0 == (5 | x)) {}
but not for
if (0 == (-5 | x)) {}
This patch changes the analysis to not look at the AST node directly to
see if it is an IntegerLiteral, but instead attempts to evaluate the
expression to see if it is an integer constant expression. This handles
unary negation signs, but also handles all the other possible operators
as well.
Fixes#42918
Differential Revision: https://reviews.llvm.org/D130510
DR2338 clarified that it was undefined behavior to set the value outside the
range of the enumerations values for an enum without a fixed underlying type.
We should diagnose this with a constant expression context.
Differential Revision: https://reviews.llvm.org/D130058
Dmitry Polukhin