I noticed another instance of the issue where references to aliases were
being replaced with aliasees, this time in InstCombine. In the instance that
I saw it turned out to be only a QoI issue (a symbol ended up being missing
from the symbol table due to the last reference to the alias being removed,
preventing HWASAN from symbolizing a global reference), but it could easily
have manifested as incorrect behaviour.
Since this is the third such issue encountered (previously: D65118, D65314)
it seems to be time to address this common error/QoI issue once and for all
and make the strip* family of functions not look through aliases.
Includes a test for the specific issue that I saw, but no doubt there are
other similar bugs fixed here.
As with D65118 this has been tested to make sure that the optimization isn't
load bearing. I built Clang, Chromium for Linux, Android and Windows as well
as the test-suite and there were no size regressions.
Differential Revision: https://reviews.llvm.org/D66606
llvm-svn: 369697
This fixes some minor grammatical issues I noticed when reading the docs, and changes the recommended feature testing approach to use __has_attribute instead of __has_extension.
llvm-svn: 369687
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
This reverts commit r369591, because it causes the formerly-reliable
-Wreturn-stack-address warning to start issuing false positives.
Testcase provided on the commit thread.
llvm-svn: 369677
This broke compiling some ASan tests with never versions of MSVC/the Win
SDK, see https://crbug.com/996675
> MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
> so should clang-cl:
> https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
>
> clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
> or if that's not passed it tries to check what the installed version of
> MSVC is and uses that, and failing that it uses a default version that's
> currently 1911. So this changes the default if no -fmsc-version flag is
> passed and no installed MSVC is detected. (It also changes the default
> if -fmsc-version is passed or MSVC is detected, and either indicates
> _MSC_VER >= 1911.)
>
> As mentioned in the MSDN article, the Windows SDK header files in
> version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
> versions do not work correctly with /Zc:twoPhase. If you need to use
> these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
> the old behavior.
>
> Fixes PR43032.
>
> Differential Revision: https://reviews.llvm.org/D66394
llvm-svn: 369647
It causes the build to fail with
"inlinable function call in a function with debug info must have a !dbg location"
in Chromium. See llvm-commits thread for more info.
(This also reverts the follow-up in r369474.)
> Fixes PR43012
>
> Differential Revision: https://reviews.llvm.org/D66328
llvm-svn: 369633
For `map`, the following restriction changed in OpenMP 5.0:
* OpenMP 4.5 [2.15.5.1, Restrictions]: "A list item cannot appear in
both a map clause and a data-sharing attribute clause on the same
construct.
* OpenMP 5.0 [2.19.7.1, Restrictions]: "A list item cannot appear in
both a map clause and a data-sharing attribute clause on the same
construct unless the construct is a combined construct."
This patch removes this restriction in the case of combined constructs
and OpenMP 5.0, and it updates Sema not to capture a scalar by copy in
the target region when `firstprivate` and `map` appear for that scalar
on a combined target construct.
This patch also adds a fixme to a test that now reveals that a
diagnostic about loop iteration variables is dropped in the case of
OpenMP 5.0. That bug exists regardless of this patch's changes.
Reviewed By: ABataev, jdoerfert, hfinkel, kkwli0
Differential Revision: https://reviews.llvm.org/D65835
llvm-svn: 369619
This patch concludes my GSoC'19 project by enabling track-conditions by default.
Differential Revision: https://reviews.llvm.org/D66381
llvm-svn: 369616
As discussed on the mailing list, notes originating from the tracking of foreach
loop conditions are always meaningless.
Differential Revision: https://reviews.llvm.org/D66131
llvm-svn: 369613
Summary:
This patch introduces `DynamicCastInfo` similar to `DynamicTypeInfo` which
is stored in `CastSets` which are storing the dynamic cast informations of
objects based on memory regions. It could be used to store and check the
casts and prevent infeasible paths.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D66325
llvm-svn: 369605
In D65724, I do a pretty thorough explanation about how I'm solving this
problem, I think that summary nails whats happening here ;)
Differential Revision: https://reviews.llvm.org/D65725
llvm-svn: 369596
Summary:
This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator
on the template is a DependentNameType - we can only put the gsl::Pointer attribute
on the underlaying record after instantiation)
inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared,
we added the gsl::Pointer on the canonical decl (the forward decl), and later when the
template was instantiated, there was no attribute on the definition so it was not instantiated).
and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to
a incomplete instantiation, and then another was copied from the template definition
when the instantiation was completed).
We now add the attributes to all redeclarations to fix thos issues and make their usage easier.
Reviewers: gribozavr
Subscribers: Szelethus, xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66179
llvm-svn: 369591
Exactly what it says on the tin! Note that we're talking about interestingness
in general, hence this isn't a control-dependency-tracking specific patch.
Differential Revision: https://reviews.llvm.org/D65724
llvm-svn: 369589
I noticed that SourceManager::translateFile has code that doesn't really make sense.
In particular, if it fails to find a FileID by comparing FileEntry * values, it tries to
look through files that have the same filename, to see if they have a matching inode to try to
find the right FileID. However, the inode comparison seem redundant, as Clang's FileManager
already deduplicates FileEntry * values by inode.
Thus the comparisons between inodes should never actually succeed, and the comparison between FileEntry * values should be sufficient here.
Differential Revision: https://reviews.llvm.org/D65481
llvm-svn: 369585
We defined (on the mailing list and here on phabricator) 2 different cases where
retrieving information about a control dependency condition is very important:
* When the condition's last write happened in a different stack frame
* When the collapse point of the condition (when we can constrain it to be
true/false) didn't happen in the actual condition.
It seems like we solved this problem with the help of expression value tracking,
and have started working on better diagnostics notes about this process.
Expression value tracking is nothing more than registering a variety of visitors
to construct reports about it. Each of the registered visitors (ReturnVisitor,
FindLastStoreVisitor, NoStoreFuncVisitor, etc) have something to go by: a
MemRegion, an SVal, an ExplodedNode, etc. For this reason, better explaining a
last write is super simple, we can always just pass on some more information to
the visitor in question (as seen in D65575).
ConditionBRVisitor is a different beast, as it was built for a different
purpose. It is responsible for constructing events at, well, conditions, and is
registered only once, and isn't a part of the "expression value tracking
family". Unfortunately, it is also the visitor to tinker with for constructing
better diagnostics about the collapse point problem.
This creates a need for alternative way to communicate with ConditionBRVisitor
that a specific condition is being tracked for for the reason of being a control
dependency. Since at almost all PathDiagnosticEventPiece construction the
visitor checks interestingness, it makes sense to pair interestingness with a
reason as to why we marked an entity as such.
Differential Revision: https://reviews.llvm.org/D65723
llvm-svn: 369583
Can't add much more to the title! This is part 1, the case where the collapse
point isn't in the condition point is the responsibility of ConditionBRVisitor,
which I'm addressing in part 2.
Differential Revision: https://reviews.llvm.org/D65575
llvm-svn: 369574
Match the behavior of D65009 under the new pass manager. This addresses
the test clang/test/CodeGen/split-lto-unit.c when running under the new
PM.
Differential Revision: https://reviews.llvm.org/D66488
llvm-svn: 369550
Add defensive check that prevents a crash when we try to evaluate a destructor
whose this-value is a concrete integer that isn't a null.
Differential Revision: https://reviews.llvm.org/D65349
llvm-svn: 369450
Calling a pure virtual method during construction or destruction
is undefined behavior. It's worth it to warn about it by default.
That part is now known as the cplusplus.PureVirtualCall checker.
Calling a normal virtual method during construction or destruction
may be fine, but does behave unexpectedly, as it skips virtual dispatch.
Do not warn about this by default, but let projects opt in into it
by enabling the optin.cplusplus.VirtualCall checker manually.
Give the two parts differentiated warning text:
Before:
Call to virtual function during construction or destruction:
Call to pure virtual function during construction
Call to virtual function during construction or destruction:
Call to virtual function during destruction
After:
Pure virtual method call:
Call to pure virtual method 'X::foo' during construction
has undefined behavior
Unexpected loss of virtual dispatch:
Call to virtual method 'Y::bar' during construction
bypasses virtual dispatch
Also fix checker names in consumers that support them (eg., clang-tidy)
because we now have different checker names for pure virtual calls and
regular virtual calls.
Also fix capitalization in the bug category.
Differential Revision: https://reviews.llvm.org/D64274
llvm-svn: 369449
If the function is marked as declare target in a standalone directive,
the delayed diagnostics is not emitted. Patch fixes this problem.
llvm-svn: 369432
Summary:
As Typo Resolution can create new TypoExprs while resolving typos,
it is necessary to recurse through the expression to search for more
typos.
This should fix the assertion failure in `clang::Sema::~Sema()`:
`DelayedTypos.empty() && "Uncorrected typos!"`
Notes:
- In case some TypoExprs are created but thrown away, Sema
now has a Vector that is used to keep track of newly created
typos.
- For expressions with multiple typos, we only give suggestions
if we are able to resolve all typos in the expression
- This patch is similar to D37521 except that it does not eagerly
commit to a correction for the first typo in the expression.
Instead, it will search for corrections which fix all of the
typos in the expression.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62648
llvm-svn: 369427
MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
so should clang-cl:
https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
or if that's not passed it tries to check what the installed version of
MSVC is and uses that, and failing that it uses a default version that's
currently 1911. So this changes the default if no -fmsc-version flag is
passed and no installed MSVC is detected. (It also changes the default
if -fmsc-version is passed or MSVC is detected, and either indicates
_MSC_VER >= 1911.)
As mentioned in the MSDN article, the Windows SDK header files in
version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
versions do not work correctly with /Zc:twoPhase. If you need to use
these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
the old behavior.
Fixes PR43032.
Differential Revision: https://reviews.llvm.org/D66394
llvm-svn: 369402
Summary:
Returns the first token in every mapping where the token is an identifier.
This API is required to be able to highlight macro expansions in clangd.
Reviewers: hokein, ilya-biryukov
Subscribers: kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66470
llvm-svn: 369385
Summary:
The 'id' matcher is not even included in the AST Matchers Reference
document, so I don't expect there to be a significant number of users.
There's no reason to provide two ways to do the exact same thing that
only have a minor syntactic difference.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66462
llvm-svn: 369380
Const, volatile, and pointer types were previously available, but not
working. This patch adds handling for OpenCL builtin functions.
Add TableGen definitions for some atomic and asynchronous builtins to
make use of the new functionality.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D63442
llvm-svn: 369373
...so that at least a preceding \param etc. that lacks a description gets a
-Wdocumentation warning (instead of erroneously treating the \retval ... text as
its paragraph).
Differential Revision: https://reviews.llvm.org/D66350
llvm-svn: 369345
This patch improves Clang call graph analysis by adding in expressions
that are not found in regular function bodies, such as default arguments
or member initializers.
Patch by Joshua Cranmer!
Differential Revision: https://reviews.llvm.org/D65453
llvm-svn: 369321
Summary:
Add `Frontend` time trace entry to `HandleTranslationUnit()` function.
Add test to check all codegen blocks are inside frontend blocks.
Also, change `--time-trace-granularity` option a bit to make sure very small
time blocks are outputed to json-file when using `--time-trace-granularity=0`.
This fixes http://llvm.org/pr41969
Reviewers: russell.gallop, lebedev.ri, thakis
Reviewed By: russell.gallop
Subscribers: vsapsai, aras-p, lebedev.ri, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D63325
llvm-svn: 369308
CGLoopInfo was keeping pointers to parent loop LoopInfos, but when the loop info vector grew, it reallocated the storage and invalidated all of the parent pointers, causing use-after-free. Manage the lifetimes of the LoopInfos separately so that the pointers aren't stale.
Patch by Bevin Hansson.
llvm-svn: 369259
Generic types are an abstraction of type sets. It mimics the way
functions are defined in the OpenCL specification. For example,
floatN can abstract all the vector sizes of the float type.
This allows to
* stick more closely to the specification, which uses generic types;
* factorize definitions of functions with numerous prototypes in the
tablegen file; and
* reduce the memory impact of functions with many overloads.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D65456
llvm-svn: 369253
Rewrite the logic for detecting if we are deducing addr space of
a pointee type to take into account special logic for arrays. For
pointers/references to arrays we can have any number of parentheses
expressions as well as nested pointers.
Differential Revision: https://reviews.llvm.org/D66137
llvm-svn: 369251
Add an option group for all of the -mlong-double-* options and make
-mlong-double-80 restore the default long double behavior for X86. The
motivations are that GNU accepts the -mlong-double-80 option and that complex
Makefiles often need a way of undoing earlier options. Prior to this commit, if
one chooses 64-bit or 128-bit long double for X86, there is no way to undo that
choice and restore the 80-bit behavior.
Differential Revision: https://reviews.llvm.org/D66055
llvm-svn: 369183
Add an option group for all of the -mlong-double-* options and make
-mlong-double-80 restore the default long double behavior for X86. The
motivations are that GNU accepts the -mlong-double-80 option and that complex
Makefiles often need a way of undoing earlier options. Prior to this commit, if
one chooses 64-bit or 128-bit long double for X86, there is no way to undo that
choice and restore the 80-bit behavior.
Differential Revision: https://reviews.llvm.org/D66055
llvm-svn: 369152
Push LR register before calling __gnu_mcount_nc as it expects the value of LR register to be the top value of
the stack on ARM32.
Differential Revision: https://reviews.llvm.org/D65019
llvm-svn: 369147
target.
According to OpenMP 5.0, if a lambda declaration and definition appears between a declare target directive and the matching end declare target directive, all variables that are captured by the lambda expression must also appear in a to clause.
llvm-svn: 369146
Summary:
Code to import "ctor initializers" at import of functions
is moved to be after the flags in the newly created function
are imported. This fixes an error when the already created but
incomplete (flags are not set) function declaration is accessed.
Reviewers: martong, shafik, a_sidorin, a.sidorin
Reviewed By: shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65935
llvm-svn: 369098
This allows the constraint A to be used in inline asm for RISC-V, which
allows an address held in a register to be used.
This patch adds the minimal amount of code required to get operands with
the right constraints to compile.
Differential Revision: https://reviews.llvm.org/D54295
llvm-svn: 369093
Summary:
This patch introduces a new `analyzer-config` configuration:
`-analyzer-config silence-checkers`
which could be used to silence the given checkers.
It accepts a semicolon separated list, packed into quotation marks, e.g:
`-analyzer-config silence-checkers="core.DivideZero;core.NullDereference"`
It could be used to "disable" core checkers, so they model the analysis as
before, just if some of them are too noisy it prevents to emit reports.
This patch also adds support for that new option to the scan-build.
Passing the option `-disable-checker core.DivideZero` to the scan-build
will be transferred to `-analyzer-config silence-checkers=core.DivideZero`.
Reviewed By: NoQ, Szelethus
Differential Revision: https://reviews.llvm.org/D66042
llvm-svn: 369078
I'd like to add these comments to warn others of problems I
encountered when trying to use `RemoveLineIfEmpty`. I originally
tried to fix the problem, but I realized I could implement the
functionality more easily and efficiently in my calling code where I
can make the simplifying assumption that there are no prior edits to
the line from which text is being removed. While I've lost the
motivation to write a fix, which doesn't look easy, I figure a warning
to others is better than silence.
I've added a unit test to demonstrate the problem. I don't know how
to mark it as an expected failure, so I just marked it disabled.
Reviewed By: jkorous
Differential Revision: https://reviews.llvm.org/D61466
llvm-svn: 369049
Allow implementations to provide complete definitions of
std::tuple_size<T>, but to omit the 'value' member to signal that T is
not tuple-like. The Microsoft standard library implements
std::tuple_size<const T> this way.
If the value member exists, clang still validates that it is an ICE, but
if it does not, then the type is considered to not be tuple-like.
Fixes PR33236
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D66040
llvm-svn: 369043
Summary:
D66168 passes size 0 structs indirectly, while the wasm backend expects it to
be passed directly. This causes subsequent variadic arguments to be read
incorrectly.
This diff changes it so that size 0 structs are passed directly.
Reviewers: dschuff, tlively, sbc100
Reviewed By: dschuff
Subscribers: jgravelle-google, aheejin, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66255
llvm-svn: 369042
This gives library implementers a way to use standards-based attributes that do not conflict with user-defined macros of the same name. Attributes in C2x require this behavior normatively (C2x 6.7.11p4), but there's no reason to not have the same behavior in C++, especially given that such attributes may be used by a C library consumed by a C++ compilation.
llvm-svn: 369033
Summary:
Previously, object files were bundled using partial linking. It resulted
in the following structure of the bundled objects:
```
<host_code>
clang-offload-bundle
__CLANG_OFFLOAD_BUNDLE__<target>
<target_code>
```
But when we tried to unbundle object files, it worked correctly only for
the target objects. The host object remains bundled. It produced a lot of
junk sections in the host object files and in some cases may caused
incorrect linking.
Patch improves bundling of the object files. After this patch the
bundled object looks like this:
```
<host_code>
clang-offload-bundle
__CLANG_OFFLOAD_BUNDLE__<target>
<target_code>
__CLANG_OFFLOAD_BUNDLE__<host>
<host_code>
```
With this structure we are able to unbundle the host object files too so
that after unbundling they are the same as were before.
The host section is bundled twice. The bundled section is used to
unbundle the original host section.
Reviewers: yaxunl, tra, jlebar, hfinkel, jdoerfert
Subscribers: caomhin, kkwli0, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65819
llvm-svn: 369019
Summary:
Make the test more portable and do not rely on the pre-bundled object
file.
Reviewers: Hahnfeld, hfinkel, jdoerfert
Subscribers: caomhin, kkwli0, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66296
llvm-svn: 369015
This is more of a temporary fix, long term, we should convert AnalyzerOptions.def
into the universally beloved (*coughs*) TableGen format, where they can more
easily be separated into developer-only, alpha, and user-facing configs.
Differential Revision: https://reviews.llvm.org/D66261
llvm-svn: 368980
New pragma "vectorize_predicate(enable)" now implies "vectorize(enable)",
and it is ignored when vectorization is disabled with e.g.
"vectorize(disable) vectorize_predicate(enable)".
Differential Revision: https://reviews.llvm.org/D65776
llvm-svn: 368970
The change in r368681 contains a (probably unintentional) behavioral change for
rewrite rules with a single matcher. Previously, the single matcher would not
need to be bound (`joinCaseMatchers` returned it directly), even though a final
DynTypeMatcher was created and bound by `buildMatcher`. With the new change, a
single matcher will be bound, in addition to the final binding (which is now in
`buildMatchers`, but happens roughly at the same point in the overall flow).
This patch simply duplicates the "final matcher" trick: it creates an extra
DynTypedMatcher for each rewrite rule case matcher, and unconditionally makes it
bindable. This is probably not the right long-term fix, but it does allow
existing code to continue to work with this interface.
Subscribers: cfe-commits, gribozavr, ymandel
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66273
llvm-svn: 368958
Summary:
Some compilers require that const fields of an object must be explicitly
initialized by the constructor. I ran into this issue building with clang
3.8 on Ubuntu 16.04.
Reviewers: compnerd, Szelethus, NoQ
Subscribers: cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66265
llvm-svn: 368950
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
When handling a member access into a non-class, non-ObjC-object type, we
would perform a lookup into the surrounding scope as if for an
unqualified lookup. If the member access was followed by a '<' and this
lookup (or the typo-correction for it) found a template name, we'd treat
the member access as naming that template.
Now we treat such accesses as never naming a template if the type of the
object expression is of vector type, so that vector component accesses
are never misinterpreted as naming something else. This is not entirely
correct, since it is in fact valid to name a template from the enclosing
scope in this context, when invoking a pseudo-destructor for the vector
type via an alias template, but that's very much a corner case, and this
change leaves that case only as broken as the corresponding case for
Objective-C types is.
This incidentally adds support for dr2292, which permits a 'template'
keyword at the start of a member access naming a pseudo-destructor.
llvm-svn: 368940
Added basic support for non-rectangular loops. It requires an additional
analysis of min/max boundaries for non-rectangular loops. Since only
linear dependency is allowed, we can do this analysis.
llvm-svn: 368903
Previously, collecting CFGElements in a set was practially impossible, because
both CFGBlock::operator[] and both the iterators returned it by value. One
workaround would be to collect the iterators instead, but they don't really
capture the concept of an element, and elements from different iterator types are incomparable.
This patch introduces CFGElementRef, a wrapper around a (CFGBlock, Index) pair,
and a variety of new iterators and iterator ranges to solve this problem.
I guess you could say that this patch took a couple iterations to get right :^)
Differential Revision: https://reviews.llvm.org/D65196
llvm-svn: 368883
This patch simply moves code that already exists into a new function.
Specifically I think it will make the BuildActions code for building a clang
job pipeline easier to read and work with.
Differential Revision: https://reviews.llvm.org/D66058
llvm-svn: 368881
Only honour format_arg attributes on -[NSBundle localizedStringForKey] when its
argument has a format specifier in it, otherwise its likely to just be a key to
fetch localized strings.
Fixes rdar://23622446
Differential revision: https://reviews.llvm.org/D27165
llvm-svn: 368878
...because we're working with a BugReporterVisitor, and the non-evaluated part
of the condition isn't in the bugpath.
Differential Revision: https://reviews.llvm.org/D65290
llvm-svn: 368853
Well, what is says on the tin I guess!
Some more changes:
* Move isInevitablySinking() from BugReporter.cpp to CFGBlock's interface
* Rename and move findBlockForNode() from BugReporter.cpp to
ExplodedNode::getCFGBlock()
Differential Revision: https://reviews.llvm.org/D65287
llvm-svn: 368836
For these macros it is the definedness that matters rather than
the value. Make new uses of these macros consistent with existing
uses.
llvm-svn: 368822
Summary:
The default expression of a parameter variable should be imported before
the parameter variable object is created. Otherwise the function is created
with an incomplete parameter variable (default argument is nullptr) and in
this intermediary state the expression is imported. This import can have
a reference to the incomplete parameter variable that causes crash.
Reviewers: martong, a.sidorin, shafik
Reviewed By: martong
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65577
llvm-svn: 368818
Exactly what it says on the tin! The comments in the code detail this a
little more too.
Differential Revision: https://reviews.llvm.org/D64272
llvm-svn: 368817
Summary: https://reviews.llvm.org/D50923 enabled the IR printing support for the new pass manager, but only for the case when `opt` tool is used as a driver. This patch is to enable the IR printing when `clang` is used as a driver.
Reviewers: fedor.sergeev, philip.pfaffe
Subscribers: cfe-commits, yamauchi, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65975
llvm-svn: 368804
Summary:
Previously __has_builtin(__builtin_*) would return false for
__builtin_*s that we modeled as keywords rather than as functions
(because they take type arguments). With this patch, all builtins
that are called with function-call-like syntax return true from
__has_builtin (covering __builtin_* and also the __is_* and __has_* type
traits and the handful of similar builtins without such a prefix).
Update the documentation on __has_builtin and on type traits to match.
While doing this I noticed the type trait documentation was out of date
and incomplete; that's fixed here too.
Reviewers: aaron.ballman
Subscribers: jfb, kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66100
llvm-svn: 368785
Summary:
Explicitly deleting the copy constructor makes compiling the function
`ento::registerGenericTaintChecker` difficult with some compilers. When we
construct an `llvm::Optional<TaintConfig>`, the optional is constructed with a
const TaintConfig reference which it then uses to invoke the deleted TaintConfig
copy constructor.
I've observered this failing with clang 3.8 on Ubuntu 16.04.
Reviewers: compnerd, Szelethus, boga95, NoQ, alexshap
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, llvm-commits, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66192
llvm-svn: 368779
When we're tracking a variable that is responsible for a null pointer
dereference or some other sinister programming error, we of course would like to
gather as much information why we think that the variable has that specific
value as possible. However, the newly introduced condition tracking shows that
tracking all values this thoroughly could easily cause an intolerable growth in
the bug report's length.
There are a variety of heuristics we discussed on the mailing list[1] to combat
this, all of them requiring to differentiate in between tracking a "regular
value" and a "condition".
This patch introduces the new `bugreporter::TrackingKind` enum, adds it to
several visitors as a non-optional argument, and moves some functions around to
make the code a little more coherent.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-June/062613.html
Differential Revision: https://reviews.llvm.org/D64270
llvm-svn: 368777
Summary:
The following code snippet taken from D64271#1572188 has an issue: namely,
because `flag`'s value isn't undef or a concrete int, it isn't being tracked.
int flag;
bool coin();
void foo() {
flag = coin();
}
void test() {
int *x = 0;
int local_flag;
flag = 1;
foo();
local_flag = flag;
if (local_flag)
x = new int;
foo();
local_flag = flag;
if (local_flag)
*x = 5;
}
This, in my opinion, makes no sense, other values may be interesting too.
Originally added by rC185608.
Differential Revision: https://reviews.llvm.org/D64287
llvm-svn: 368773
During the evaluation of D62883, I noticed a bunch of totally
meaningless notes with the pattern of "Calling 'A'" -> "Returning value"
-> "Returning from 'A'", which added no value to the report at all.
This patch (not only affecting tracked conditions mind you) prunes
diagnostic messages to functions that return a value not constrained to
be 0, and are also linear.
Differential Revision: https://reviews.llvm.org/D64232
llvm-svn: 368771
They're useful when trying to understand what's going on
inside your LazyCompoundValues.
Differential Revision: https://reviews.llvm.org/D65427
llvm-svn: 368769
When -trim-egraph is unavailable (say, when you're debugging a crash on
a real-world code that takes too long to reduce), it makes sense to view
the untrimmed graph up to the crashing node's predecessor, then dump the ID
(or a pointer) of the node in the attached debugger, and then trim
the dumped graph in order to keep only paths from the root to the node.
The newly added --to flag does exactly that:
$ exploded-graph-rewriter.py ExprEngine.dot --to 0x12229acd0
Multiple nodes can be specified. Stable IDs of nodes can be used
instead of pointers.
Differential Revision: https://reviews.llvm.org/D65345
llvm-svn: 368768
Explorers aren't the right abstraction. For the purposes of displaying svg files
we don't care in which order do we explore the nodes. We may care about this for
other analyses, but we're not there yet.
The function of cutting out chunks of the graph is performed poorly by
the explorers, because querying predecessors/successors on the explored nodes
yields original successors/predecessors even if they aren't being explored.
Introduce a new entity, "trimmers", that do one thing but to it right: cut out
chunks of the graph. Trimmers mutate the graph, so stale edges aren't even
visible to their consumers in the pipeline. Additionally, trimmers are
intrinsically composable: multiple trimmers can be applied to the graph
sequentially.
Refactor the single-path explorer into the single-path trimmer.
Rename the test file for consistency.
Differential Revision: https://reviews.llvm.org/D65344
llvm-svn: 368767
Change the default behavior: the tool no longer dumps the rewritten .dot file
to stdout, but instead it automatically converts it into an .html file
(which essentially wraps an .svg file) and immediately opens it with
the default web browser.
This means that the tool should now be fairly easy to use:
$ exploded-graph-rewriter.py /tmp/ExprEngine.dot
The benefits of wrapping the .svg file into an .html file are:
- It'll open in a web browser, which is the intended behavior.
An .svg file would be open with an image viewer/editor instead.
- It avoids the white background around the otherwise dark svg area
in dark mode.
The feature can be turned off by passing a flag '--rewrite-only'.
The LIT substitution is updated to enforce the old mode because
we don't want web browsers opening on our buildbots.
Differential Revision: https://reviews.llvm.org/D65250
llvm-svn: 368766
r367979 changed DirectoryWatcher::Create to return an llvm::Expected.
Adjust the Windows stub accordingly.
(upstreamed from github.com/apple/swift-clang)
llvm-svn: 368762
This is just a code skeleton for DirectoryWatcher-windows.cpp so the
build on Windows stops breaking.
(upstreamed from github.com/apple/swift-clang)
llvm-svn: 368761
I feel this is kinda important, because in a followup patch I'm adding different
kinds of interestingness, and propagating the correct kind in BugReporter.cpp is
just one less thing to worry about.
Differential Revision: https://reviews.llvm.org/D65578
llvm-svn: 368755
Apparently this does literally nothing.
When you think about this, it makes sense. If something is really important,
we're tracking it anyways, and that system is sophisticated enough to mark
actually interesting statements as such. I wouldn't say that it's even likely
that subexpressions are also interesting (array[10 - x + x]), so I guess even
if this produced any effects, its probably undesirable.
Differential Revision: https://reviews.llvm.org/D65487
llvm-svn: 368752
Summary:
In the WebAssembly backend, when lowering variadic function calls, non-single
member aggregate type arguments are always passed by pointer.
However, when emitting va_arg code in clang, the arguments are instead read as
if they are passed directly. This results in the pointer being read as the
actual structure.
Fixes https://github.com/emscripten-core/emscripten/issues/9042.
Reviewers: tlively, sbc100, kripken, aheejin, dschuff
Reviewed By: dschuff
Subscribers: dschuff, jgravelle-google, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66168
llvm-svn: 368750
Peter Collingbourne