Fixes#111854
---
The issue arises when `GetExprRange` encounters a `ConditionalOperator`
with a `CXXThrowExpr`
```md
ConditionalOperator 0x1108658e0 'int'
|-CXXBoolLiteralExpr 0x110865878 '_Bool' true
|-CXXThrowExpr 0x1108658a8 'void'
| `-IntegerLiteral 0x110865888 'int' 0
`-IntegerLiteral 0x1108658c0 'int' 0
```
ed3d051782/clang/lib/Sema/SemaChecking.cpp (L9628-L9631)
The current behavior causes the `GetExprRange` to proceed with the throw
expression (`CO->getTrueExpr()`/`void` type)
Follow-on from #99656, which introduces 2nd pass caller/callee analysis
for function effects.
Wrote a new documentation page, derived directly from the RFC posted to
LLVM Discourse earlier this year.
---------
Co-authored-by: Doug Wyatt <dwyatt@apple.com>
Co-authored-by: Sirraide <aeternalmail@gmail.com>
This implements a warning that's similar to what GCC does in that
context: both memcpy and memset require their first and second operand
to be trivially copyable, let's warn if that's not the case.
This change moves the `alpha.nondeterministic.PointerSorting` and
`alpha.nondeterministic.PointerIteration` static analyzer checkers to a
single `clang-tidy` check. Those checkers were implemented as simple
`clang-tidy` check-like code, wrapped in the static analyzer framework.
The documentation was updated to describe what the checks can and cannot
do, and testing was completed on a broad set of open-source projects.
Co-authored-by: Vince Bridgers <vince.a.bridgers@ericsson.com>
The ClangSA documentation lives in RST format, and the FAQ section of
the old webpage is also migrated from HTML with this change.
---------
Co-authored-by: Donát Nagy <donat.nagy@ericsson.com>
Fixes#112140
---
```
CXXConstructExpr 0x14209e580 'const S':'const struct S' contains-errors 'void (const int &)' list
`-CXXDefaultArgExpr 0x14209e500 'const int' contains-errors
`-RecoveryExpr 0x14209daf0 'const int' contains-errors
```
This change resolves an issue with evaluating `ArrayFiller` initializers
in _dependent_ contexts, especially when they involve a `RecoveryExpr`.
In certain cases, `ArrayFiller` initializers containing a `RecoveryExpr`
from earlier errors are incorrectly passed to `EvaluateInPlace`, causing
evaluation failures when they are value-dependent.
When this is the case, the initializer is processed through
`EvaluateDependentExpr`, which prevents unnecessary evaluation attempts
and ensures proper handling of value-dependent initializers in
`ArrayFillers`.
Fixes: #113187
Avoid to create init function since clang does not support global
variable with flexible array init.
It will cause assertion failure later.
Fixed: #113044
the type of `ArrayTypeTraitExpr` can be changed, use i32 directly is
incorrect.
---------
Co-authored-by: Eli Friedman <efriedma@quicinc.com>
Nested lambdas could refer to outer packs that would be expanded by a
larger CXXFoldExpr, in which case that reference could happen to be a
full expression containing intermediate types/expressions, e.g.
SubstTemplateTypeParmPackType/FunctionParmPackExpr. They are designated
as "UnexpandedPack" dependencies but don't introduce new packs anyway.
This also handles a missed case for VarDecls, where the flag of
ContainsUnexpandedPack was not propagated up to the surrounding lambda.
Fixes#112352
According to [P0533R9](https://wg21.link/P0533R9), the C++ standard
library functions corresponding to the C macros in `[c.math.abs]` are
now `constexpr`.
To implement this feature in libc++, we must make the built-in abs
function `constexpr`. This patch adds the implementation of a
`constexpr` abs function for the current constant evaluator and the new
bytecode interpreter.
It is important to note that in 2's complement systems, the absolute
value of the most negative value is out of range. In gcc, it will result
in an out-of-range error and will not be evaluated as constants. We
follow the same approach here.
This prevents changing cv-qualification from const to volatile or vice
versa, for example.
https://eel.is/c++draft/class.virtual#8.3
Previously, we checked that the new type is the same or more qualified
to return an error, but the standard requires the new type to be the
same or less qualified and since the cv-qualification is only partially
ordered, we cannot rely on a check on whether it is more qualified to
return an error. Now, we reversed the condition to check whether the old
is at least as qualified, and return an error if it is not.
Also, adjusted the error name and message to clarify the requirement and
added a missing closing parenthesis.
Added tests to cover different use cases for classes with different
qualifications and also refactored them to make them easier to follow:
1. Use override to make sure the function names actually match.
2. Named the function in a more descriptive way to clarify what each use
case is checking.
Fixes: #111742
CStringChecker has a sub-checker alpha.unix.cstring.NotNullTerminated
which checks for invalid objects passed to string functions. The checker
and its name are not exact and more functions could be checked, this
change only adds some tests and improves documentation.
This PR would fix#16855 .
The correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The lookup before
does and because of this some valid programs are not accepted.
An example scenario of a valid program being declined is when you have a struct (let's call it `y`) inheriting from another struct with a name `x` but the struct `y` is in a namespace that is also called `x`:
```
struct x
{};
namespace
{
namespace x
{
struct y : x
{};
}
}
```
This shall be accepted because:
```
C++ [class.derived]p2 (wrt lookup in a base-specifier): The lookup for
// the component name of the type-name or simple-template-id is type-only.
```
When parsing its function parameters, we don't change the CurContext to
the lambda's function declaration. However,
CheckIfAnyEnclosingLambdasMustCaptureAnyPotentialCaptures() has not
yet adapted to such behavior when nested lambdas come into play.
Consider the following case,
struct Foo {};
template <int, Foo f> struct Arr {};
constexpr void foo() {
constexpr Foo F;
[&]<int I>() {
[&](Arr<I, F>) {};
}.template operator()<42>();
}
As per [basic.def.odr]p5.2, the use of F constitutes an ODR-use. And
per [basic.def.odr]p10, F should be ODR-usable in that interleaving
scope.
We failed to accept the case because the call to tryCaptureVariable()
in getStackIndexOfNearestEnclosingCaptureCapableLambda() suggested
that F is needlessly captureable. That was due to a missed handling
for AfterParameterList in FunctionScopeIndexToStopAt, where it still
presumed DC and LSI matched.
Fixes#47400Fixes#90896
* Convert `ReflowComments` from boolean into a new `enum` which can take
on the value `RCS_Never`, `RCS_IndentOnly`, or `RCS_Always`. The first
one is equivalent to the old `false`, the third one is `true`, and the
middle one means that multiline comments should only have their
indentation corrected, which is what Doxygen users will want.
* Preserve backward compatibility while parsing `ReflowComments`.
This patch reapplies #111173, fixing a bug when instantiating dependent
expressions that name a member template that is later explicitly
specialized for a class specialization that is implicitly instantiated.
The bug is addressed by adding the `hasMemberSpecialization` function,
which return `true` if _any_ redeclaration is a member specialization.
This is then used when determining the instantiation pattern for a
specialization of a template, and when collecting template arguments for
a specialization of a template.
Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```
When we encounter `^Ts`, we try to parse a block and subsequently call
`DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which
sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the
`LambdaScopeInfo` of the enclosing lambda. However, the entire block is
subsequently discarded entirely because it isn’t even syntactically
well-formed. As a result, `ContainsUnexpandedParameterPack` is `true`
despite the lambda’s body no longer containing any unexpanded packs,
which causes an assertion the next time
`DiagnoseUnexpandedParameterPack()` is called.
This pr moves handling of unexpanded parameter packs into
`CapturingScopeInfo` instead so that the same logic is used for both
blocks and lambdas. This fixes this issue since the
`ContainsUnexpandedParameterPack` flag is now part of the block (and
before that, its `CapturingScopeInfo`) and no longer affects the
surrounding lambda directly when the block is parsed. Moreover, this
change makes blocks actually usable with pack expansion.
This fixes#109148.
Add a new enumeration `SuppressInlineNamespaceMode` to `PrintingPolicy` that
is explicit about how to handle inline namespaces. `SuppressInlineNamespace`
uses that enumeration now instead of a Boolean value.
Specializing a template from an inline namespace should be transparent.
For instance
```
namespace foo {
inline namespace v1 {
template<typename A>
void function(A&);
}
}
namespace foo {
template<>
void function<int>(int&);
}
```
`hasName` should match both declarations of `foo::function`.
Makes the behavior of `matchesNodeFullSlow` and `matchesNodeFullFast`
consistent, fixing an assert inside `HasNameMatcher::matchesNode`.
It would be nice to see what our users think about this change, as this
is something that WG21/EWG quite wants to fix a handful of questionable
issues with UB. Depending on the outcome of this after being committed,
we might instead suggest EWG undeprecate this, and require a bit of
'magic' from the lexer.
Additionally, this patch makes it so we emit this diagnostic ALSO in
cases where the literal name is reserved. It doesn't make sense to limit
that.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
