BEFORE this patch, when clang handles constraints like C1 || C2 where C1 evaluates to false and C2 evaluates to true, it emitted irrelevant diagnostics about the falsity of C1.
This patch removes the irrelevant diagnostic information generated during the evaluation of C1 if C2 evaluates to true.
Fixes https://github.com/llvm/llvm-project/issues/54678
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D157526
So that the values that are accessed via such accessors can be analyzed
as a limited version of context-sensitive analysis. We can potentially
do this only when some option is set, but doing additional modeling like
this won't be expensive and intrusive, so we do it by default for now.
Adds documentation for the X86 `__attribute__((interrupt))` attribute,
in a similar format to interrupt attributes of
other platforms.
Migrated from https://reviews.llvm.org/D159317
See issue https://github.com/llvm/llvm-project/issues/62594
This code does not work on win32:
auto lstatic = []() static { return 0; };
int (*f2)(void) = lstatic;
Since a calling convention such as CC_X86ThisCall can rightly interfere with the implicit pointer to function conversion if erroneously marked on a static function, the fix entails checking the 'static' specifier on the lambda declarator prior to assigning it a calling convention of an non-static member (which pre-c++23 made sense).
When a statement following a case label had to be broken into multiple
lines, the continuation parts were not indented correctly.
Old:
```Verilog
case (data)
16'd0:
result = // break here
10'b0111111111;
endcase
```
New:
```Verilog
case (data)
16'd0:
result = // break here
10'b0111111111;
endcase
```
Verilog case labels and the following statements are on the same
unwrapped line due to the difficulty of identifying them. So there was a
rule in `getNewLineColumn` to add a level of indentation to the part
following the case label. However, in case the line had to be broken
again, the code at the end of the function would see that the line was
already broken with the continuation part indented, so it would not
indent it more. Now `State.FirstIndent` is changed as well for the part
following the case label, so the logic for determining when to add a
continuation indentation works.
For `c-header` and `c++-header` inputs, Clang driver selects the
`-emit-pch` frontend action and defaults the output suffix name to
`.gch` (except clang-cl, which uses `.pch`) to follow GCC.
```
clang -c a.h # a.h.gch
clang -xc++-header -c a.h # a.h.gch
```
In every other place we prefer `.pch` to `.gch`. E.g. `-include a.h`
probes `a.h.pch` before `a.h.gch`, and we have `-include-pch` instead of
`-include-gch`. (Clang and GCC use different extension names for C++
modules as well.)
This change isn't disruptive because:
* Most newer build systems specify explicit output filenames and are
unaffected
* Implicit output name users almost assuredly use something like
`-include a.h`, which probes both `a.h.pch` and `a.h.gch`[^1]
[^1]: In the future, we shall stop probing `a.h.gch` for `-include a.h`
as the
compatibility intended behavior actually gets in the way
(https://discourse.llvm.org/t/how-to-have-clang-ignore-gch-directories/51835).
This patch is a prerequisite.
Debug info correlation is an option in InstrProfiling pass, which is used by
both IR instrumentation and front-end instrumentation. So, Clang coverage can
also benefits the binary size saving from it.
Reviewed By: ellis
Differential Revision: https://reviews.llvm.org/D157913
One of the main user of these kind of coroutines is swift. There yield-once (`retcon.once`) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes.
However, in some cases it might be useful also to allow these coroutines to produce a normal result, but there is no convenient way to represent this (as compared to switched-resume kind of coroutines where C++ `co_return`
is transformed to a member / callback call on promise object).
The extension is simple: we allow continuation function to have a non-void result and accept optional extra arguments via a special `llvm.coro.end.result` intrinsic that would essentially forward them as normal results.
Reapply after fixing the test by enabling the `debug.ExprInspection` checker.
-----
NonLoc symbolic SVal to Loc casts are not supported except for
nonloc::ConcreteInt.
This change simplifies the source SVals so that the more casts can
go through nonloc::ConcreteInt->loc::ConcreteInt path. For example:
void test_simplified_before_cast_add(long long t1) {
long long t2 = t1 + 3;
if (!t2) {
int *p = (int *) t2;
clang_analyzer_eval(p == 0); // expected-warning{{TRUE}}
}
}
If simplified, 't2' is 0, resulting 'p' is nullptr, otherwise 'p'
is unknown.
Fixes#62232
The test demonstrates that the `this` pointer seen in the constructor
has the
same value as the address of the variable the object is constructed
into.
This reverts commit 3ebf3dd30da219f9f9aee12f42d45d18d55e7580.
I thought "Mergeing" will wait and confirm if the checks pass, and only
merge it if they succeed. Apparently, it's not the case here xD
The test is just broken in x86. See:
https://lab.llvm.org/buildbot/#/builders/109/builds/73686
NonLoc symbolic SVal to Loc casts are not supported except for
nonloc::ConcreteInt.
This change simplifies the source SVals so that the more casts can go
through nonloc::ConcreteInt->loc::ConcreteInt path. For example:
```c
void test_simplified_before_cast_add(long long t1) {
long long t2 = t1 + 3;
if (!t2) {
int *p = (int *) t2;
clang_analyzer_eval(p == 0); // expected-warning{{TRUE}}
}
}
```
If simplified, `t2` is 0, resulting `p` is nullptr, otherwise `p` is
unknown.
Fixes#62232
91088978d712cd7b33610c59f69d87d5a39e3113 shouldn't have removed an
additional check that field has incomplete array type.
Fixes https://github.com/llvm/llvm-project/issues/66300
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
In C, we don't get a evaluateAsInitializer() call for all global
declarations, yet we have to handle DeclRefExpr pointing to them.
Differential Revision: https://reviews.llvm.org/D156794
This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.
This matches other nearby enums.
For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::
Currently, clang emits LLVM IR that fails verifier for the following
code:
```
template<typename T>
__global__ void foo(T x);
void bar() {
foo<<<1, 1>>>(0);
}
```
This is due to clang putting the kernel handle for foo into comdat,
which is not allowed, since the kernel handle is a declaration.
The siutation is similar to calling a declaration-only template
function. The callee will be a declaration in LLVM IR and won't be put
into comdat. This is in contrast to calling a template function with
body, which will be put into comdat.
Fixes: SWDEV-419769
In C++ it seems it is legit to use base class's operator (e.g. `using
Base::operator=`) to perform copy if the base class is the common
ancestor of the source and destination object. In such a case we
shouldn't try to access fields beyond that of the base class, however
such a case seems to be very rare (typical code would implement a copy
constructor instead), and could add complexities, so in this patch we
simply bail if the method operator's parent class is different from the
type of the destination object that this framework recognizes.
This reverts commit 070493ddbd9473499d6f00ca62bc6aa92808ed79 (and
relands the original change). This removes a test run that makes an
assumption of RTTI being on by default for a given target.
This records facts that are not sensitive to the current flow condition,
and should apply to all environments.
The motivating case is recording information about where a Value
originated, such as nullability:
- we may see the same Value for multiple expressions (e.g. reads of the
same field) in multiple environments (multiple blocks or iterations)
- we want to record information only when we first see the Value
(e.g. Nullability annotations on fields only add information if we
don't know where the value came from)
- this information should be expressible as a SAT condition
- we must add this SAT condition to every environment where the
Value may appear
We solve this by recording the information in the global condition.
This doesn't seem particularly elegant, but solves the problem and is
a fairly small and natural extension of the Environment.
Alternatives considered:
- store the constraint directly as a property on the Value.
But it's more composable for such properties to always be variables
(AtomicBoolValue), and constrain them with SAT conditions.
- add a hook whenever values are created, giving the analysis the
chance to populate them.
However the framework relies on/provides the ability to construct
values in arbitrary places without providing the context such a hook
would need, this would be a very invasive change.
Now. string literals in lines beginning with `export type` will not be
broken.
The case was missed in 5db201fb75e6. I don't know TypeScript. And
merging GitHub pull requests seems to be a little too easy. So it got
committed before the reviewers had a chance to find edge cases.
Functions like `fgets`, `strlen`, `strcat` propagate taint.
However, their `wchar_t` variants don't. This patch fixes that.
Notice, that there could be many more APIs missing.
This patch intends to fix those that so far surfaced,
instead of exhaustively fixing this issue.
https://github.com/llvm/llvm-project/pull/66074
The `stdin` declaration should be within `extern "C" {...}`, in C++
mode. In addition, it should be also marked `extern` in both C and
C++ modes.
I tightened the check to ensure we only accept `stdin` if both of these
match. However, from the Juliet test suite's perspective, this commit
should not matter.
https://github.com/llvm/llvm-project/pull/66074
Recent changes in StdLibraryFunctionsChecker introduced a situation
where the checker sequentially performed two state transitions to add
two separate note tags.
In the unlikely case when the updated state (the variable `NewState`)
was posteriorly overconstrained, the engine marked the node after the
first state transition as a sink to stop the "natural" graph exploration
after that point.
However, in this particular case the checker tried to directly add a
second node, and this triggered an assertion in the `addPredecessor()`
method of `ExplodedNode`.
This commit introduces an explicit `isSink()` check to avoid this crash.
To avoid similar bugs in the future, perhaps it would be possible to
tweak `addTransition()` and ensure that it returns `nullptr` when it
would return a sink node (to unify the two possible error conditions).
This crash was observed in an analysis of the curl project (in a very
long and complex function), and there I validated that this is the root
cause, but I don't have a self-contained testcase that can trigger the
creation of a PosteriorlyOverconstrained node in this situation.
