Commit Graph

2375 Commits

Author SHA1 Message Date
Artem Dergachev 214f68e7a1 Revert "[analyzer] A speculative attempt to avoid gcc-7 crashes..."
This reverts commit r372940 which was an overreaction to a flaky buildbot.

llvm-svn: 373005
2019-09-26 18:52:00 +00:00
Artem Dergachev d9b477af8f [analyzer] A speculative attempt to avoid gcc-7 crashes caused by r372942.
llvm-svn: 372945
2019-09-26 07:01:31 +00:00
Artem Dergachev 4ed9793f98 [analyzer] Avoid small vectors of non-default-constructibles.
Unconfuses certain compilers.

llvm-svn: 372942
2019-09-26 06:33:21 +00:00
Kristof Umann b8ac93c73b [analyzer] PR43102: Fix an assertion and an out-of-bounds error for diagnostic location construction
Summary:
https://bugs.llvm.org/show_bug.cgi?id=43102

In today's edition of "Is this any better now that it isn't crashing?", I'd like to show you a very interesting test case with loop widening.

Looking at the included test case, it's immediately obvious that this is not only a false positive, but also a very bad bug report in general. We can see how the analyzer mistakenly invalidated `b`, instead of its pointee, resulting in it reporting a null pointer dereference error. Not only that, the point at which this change of value is noted at is at the loop, rather then at the method call.

It turns out that `FindLastStoreVisitor` works correctly, rather the supplied explodedgraph is faulty, because `BlockEdge` really is the `ProgramPoint` where this happens.
{F9855739}
So it's fair to say that this needs improving on multiple fronts. In any case, at least the crash is gone.

Full ExplodedGraph: {F9855743}

Reviewers: NoQ, xazax.hun, baloghadamsoftware, Charusso, dcoughlin, rnkovacs, TWeaver

Subscribers: JesperAntonsson, uabelho, Ka-Ka, bjope, whisperity, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66716

llvm-svn: 372269
2019-09-18 22:24:26 +00:00
Kristof Umann 72649423c0 [analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker,
but in the very early years, this wasn't the case, and code originating from the
early 2010's still incorrectly refer to checkers as checks.

This patch attempts to hunt down most of these, aiming to refer to checkers as
checkers, but preserve references to callback functions (like checkPreCall) as
checks.

Differential Revision: https://reviews.llvm.org/D67140

llvm-svn: 371760
2019-09-12 19:09:24 +00:00
Artem Dergachev f0bb45fac3 [analyzer] NFC: Move PathDiagnostic classes to libAnalysis.
At this point the PathDiagnostic, PathDiagnosticLocation, PathDiagnosticPiece
structures no longer rely on anything specific to Static Analyzer, so we can
move them out of it for everybody to use.

PathDiagnosticConsumers are still to be handed off.

Differential Revision: https://reviews.llvm.org/D67419

llvm-svn: 371661
2019-09-11 20:54:27 +00:00
Artem Dergachev 2bce23a4f8 [analyzer] NFC: Move resetDiagnosticLocationToMainFile() to BugReporter.
This method of PathDiagnostic is a part of Static Analyzer's particular
path diagnostic construction scheme. As such, it doesn't belong to
the PathDiagnostic class, but to the Analyzer.

Differential Revision: https://reviews.llvm.org/D67418

llvm-svn: 371660
2019-09-11 20:54:24 +00:00
Artem Dergachev 6b85f8e99b [analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.
These static functions deal with ExplodedNodes which is something we don't want
the PathDiagnostic interface to know anything about, as it's planned to be
moved out of libStaticAnalyzerCore.

Differential Revision: https://reviews.llvm.org/D67382

llvm-svn: 371659
2019-09-11 20:54:21 +00:00
Artem Dergachev 8535b8ecf2 [analyzer] NFC: Re-implement stack hints as a side map in BugReport.
That's one of the few random entities in the PathDiagnostic interface that
are specific to the Static Analyzer. By moving them out we could let
everybody use path diagnostics without linking against Static Analyzer.

Differential Revision: https://reviews.llvm.org/D67381

llvm-svn: 371658
2019-09-11 20:54:17 +00:00
Artem Dergachev 589273bebd [analyzer] NFC: Simplify bug report equivalence classes to not be ilists.
Use a vector of unique pointers instead.

Differential Revision: https://reviews.llvm.org/D67024

llvm-svn: 371451
2019-09-09 20:34:44 +00:00
Artem Dergachev 2f169e7cdd [analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.
Checkers are now required to specify whether they're creating a
path-sensitive report or a path-insensitive report by constructing an
object of the respective type.

This makes BugReporter more independent from the rest of the Static Analyzer
because all Analyzer-specific code is now in sub-classes.

Differential Revision: https://reviews.llvm.org/D66572

llvm-svn: 371450
2019-09-09 20:34:40 +00:00
Artem Dergachev 6cee434ed1 [analyzer] Add minimal support for fix-it hints.
Allow attaching fixit hints to Static Analyzer BugReports.

Fixits are attached either to the bug report itself or to its notes
(path-sensitive event notes or path-insensitive extra notes).

Add support for fixits in text output (including the default text output that
goes without notes, as long as the fixit "belongs" to the warning).

Add support for fixits in the plist output mode.

Implement a fixit for the path-insensitive DeadStores checker. Only dead
initialization warning is currently covered.

Implement a fixit for the path-sensitive VirtualCall checker when the virtual
method is not pure virtual (in this case the "fix" is to suppress the warning
by qualifying the call).

Both fixits are under an off-by-default flag for now, because they
require more careful testing.

Differential Revision: https://reviews.llvm.org/D65182

llvm-svn: 371257
2019-09-06 20:55:29 +00:00
Artem Dergachev 2b1b4cab96 [analyzer] pr43179: Make CallDescription defensive against C variadic functions.
Most functions that our checkers react upon are not C-style variadic functions,
and therefore they have as many actual arguments as they have formal parameters.

However, it's not impossible to define a variadic function with the same name.
This will crash any checker that relies on CallDescription to check the number
of arguments but silently assumes that the number of parameters is the same.

Change CallDescription to check both the number of arguments and the number of
parameters by default.

If we're intentionally trying to match variadic functions, allow specifying
arguments and parameters separately (possibly omitting any of them).
For now we only have one CallDescription which would make use of those,
namely __builtin_va_start itself.

Differential Revision: https://reviews.llvm.org/D67019

llvm-svn: 371256
2019-09-06 20:55:24 +00:00
Artem Dergachev 630f7daf80 [analyzer] Fix analyzer warnings on analyzer.
Write tests for the actual crash that was found. Write comments and refactor
code around 17 style bugs and suppress 3 false positives.

Differential Revision: https://reviews.llvm.org/D66847

llvm-svn: 370246
2019-08-28 18:44:38 +00:00
Artem Dergachev 0909a392f3 [analyzer] pr43036: Fix support for operator 'sizeof...'.
It was known to be a compile-time constant so it wasn't evaluated during
symbolic execution, but it wasn't evaluated as a compile-time constant either.

Differential Revision: https://reviews.llvm.org/D66565

llvm-svn: 370245
2019-08-28 18:44:35 +00:00
Artem Dergachev 8b2a39e937 [analyzer] Trust global initializers when analyzing main().
If the global variable has an initializer, we'll ignore it because we're usually
not analyzing the program from the beginning, which means that the global
variable may have changed before we start our analysis.

However when we're analyzing main() as the top-level function, we can rely
on global initializers to still be valid. At least in C; in C++ we have global
constructors that can still break this logic.

This patch allows the Static Analyzer to load constant initializers from
global variables if the top-level function of the current analysis is main().

Differential Revision: https://reviews.llvm.org/D65361

llvm-svn: 370244
2019-08-28 18:44:32 +00:00
Joe Ranieri fce4324f92 Update the SARIF exporter to SARIF 2.1
This updates the SARIF exporter to produce SARIF 2.1 output. The bulk of the diffs come from two changes to SARIF:
* https://github.com/oasis-tcs/sarif-spec/issues/309
* https://github.com/oasis-tcs/sarif-spec/issues/179

Differential Revision: https://reviews.llvm.org/D65211

llvm-svn: 370068
2019-08-27 14:43:54 +00:00
Joe Ranieri 3385c5cc4d Fix a SARIF exporter crash with macro expansions
Differential Revision: https://reviews.llvm.org/D65209

llvm-svn: 370061
2019-08-27 14:20:27 +00:00
Joe Ranieri 68a6a28ef8 Fix text range end columns in SARIF to be exclusive
According to the SARIF specification, "a text region does not include the character specified by endColumn".

Differential Revision: https://reviews.llvm.org/D65206

llvm-svn: 370060
2019-08-27 13:49:45 +00:00
Benjamin Kramer dc5f805d31 Do a sweep of symbol internalization. NFC.
llvm-svn: 369803
2019-08-23 19:59:23 +00:00
Artem Dergachev 62a76d0ae3 [analyzer] CastValueChecker: Provide DynamicTypeMap with pointer types only.
The idea to drop this requirement is good, but for now every other user
of DynamicTypeInfo expects pointer types.

Fixes a crash.

llvm-svn: 369728
2019-08-23 03:24:01 +00:00
Artem Dergachev 0900b77db2 [analyzer] DynamicTypeInfo: Avoid putting null regions into dynamic typemap.
Fixes a crash.

llvm-svn: 369726
2019-08-23 03:23:55 +00:00
Kristof Umann 58eb033a49 [analyzer] Don't track the condition of foreach loops
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
2019-08-22 02:44:19 +00:00
Csaba Dabis e4bf456fce [analyzer] CastValueChecker: Rewrite dead header hotfix
llvm-svn: 369607
2019-08-22 00:36:42 +00:00
Csaba Dabis 0202c3596c [analyzer] CastValueChecker: Store the dynamic types and casts
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
2019-08-22 00:20:36 +00:00
Csaba Dabis b73a5711f6 [analyzer] TrackConstraintBRVisitor: Do not track unknown values
Summary: -

Reviewers: NoQ, Szelethus

Reviewed By: NoQ, Szelethus

Differential Revision: https://reviews.llvm.org/D66267

llvm-svn: 369604
2019-08-22 00:06:58 +00:00
Kristof Umann d9a81ccf05 [analyzer] Mention whether an event is about a condition in a bug report part 2
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
2019-08-21 22:38:00 +00:00
Kristof Umann 49ac7ece16 [analyzer] Don't make ConditionBRVisitor events prunable when the condition is an interesting field
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
2019-08-21 21:59:22 +00:00
Kristof Umann fff01c8ec2 [analyzer][NFC] Add different interestingness kinds
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
2019-08-21 21:33:25 +00:00
Kristof Umann da648ab8de [analyzer] Mention whether an event is about a condition in a bug report part 1
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
2019-08-21 20:43:27 +00:00
Dmitri Gribenko 6b9d7c9da5 Removed some dead code in BugReporter and related files
Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66473

llvm-svn: 369504
2019-08-21 08:48:24 +00:00
Artem Dergachev 3fdc427f0b [analyzer] NFC: Remove the BugTypes set from BugReporter.
Its only purpose was to avoid a bug that's caused by
making a virtual call in BugReporter's destructor.

llvm-svn: 369451
2019-08-20 21:41:20 +00:00
Artem Dergachev 8eb7a74b78 [analyzer] Fix a crash when destroying a non-region.
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
2019-08-20 21:41:17 +00:00
Artem Dergachev d3971fe97b [analyzer] Improve VirtualCallChecker and enable parts of it by default.
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
2019-08-20 21:41:14 +00:00
Artem Dergachev ee92f12fd1 [analyzer] NFC: Rename GRBugReporter to PathSensitiveBugReporter.
The GR prefix is super ancient.

llvm-svn: 369320
2019-08-20 02:15:50 +00:00
Artem Dergachev 48786cf8d3 [analyzer] NFC: Drop support for extra text attached to bug reports.
It was introduced in 2011 but never used since then.

llvm-svn: 369319
2019-08-20 02:15:47 +00:00
Kristof Umann 032e1fdcd4 [analyzer] Turn an assert into an if condition
Shocker, turns out that terminator conditions that are binary operators
aren't always logical operators.

llvm-svn: 369195
2019-08-17 16:49:54 +00:00
Csaba Dabis a079a42708 [analyzer] Analysis: Silence checkers
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
2019-08-16 01:53:14 +00:00
Jonas Devlieghere 2b3d49b610 [Clang] Migrate llvm::make_unique to std::make_unique
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
2019-08-14 23:04:18 +00:00
Kristof Umann dd53bdbfde [analyzer][CFG] Don't track the condition of asserts
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
2019-08-14 12:20:08 +00:00
Kristof Umann 967583bc08 [analyzer] Note last writes to a condition only in a nested stackframe
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
2019-08-14 09:39:38 +00:00
Haojian Wu ec25edc17a Fix the -Wunused-variable warning.
llvm-svn: 368808
2019-08-14 08:20:42 +00:00
Kristof Umann 3f7c66d551 [analyzer][NFC] Prepare visitors for different tracking kinds
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
2019-08-14 00:48:57 +00:00
Kristof Umann 0df9c8c578 [analyzer] Track the right hand side of the last store regardless of its value
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
2019-08-13 23:48:10 +00:00
Kristof Umann 46929df723 [analyzer] Prune calls to functions with linear CFGs that return a non-zero constrained value
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
2019-08-13 23:22:33 +00:00
Kristof Umann e1117addd6 [analyzer][NFC] Make sure that the BugReport is not modified during the construction of non-visitor pieces
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
2019-08-13 22:03:08 +00:00
Kristof Umann 6c1b19ac9e [analyzer][NFC] Refactoring BugReporter.cpp P6.: Completely get rid of interestingness propagation
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
2019-08-13 21:48:17 +00:00
Kristof Umann edb788592d [analyzer][NFC] Address inlines of D65484
llvm-svn: 368745
2019-08-13 20:42:48 +00:00
Kristof Umann f9d75bede8 [analyzer][NFC] Refactoring BugReporter.cpp P5.: Compact mile long function invocations into objects
In D65379, I briefly described the construction of bug paths from an
ExplodedGraph. This patch is about refactoring the code processing the bug path
into a bug report.

A part of finding a valid bug report was running all visitors on the bug path,
so we already have a (possibly empty) set of diagnostics for each ExplodedNode
in it.
Then, for each diagnostic consumer, we construct non-visitor diagnostic pieces.

* We first construct the final diagnostic piece (the warning), then
* We start ascending the bug path from the error node's predecessor (since the
error node itself was used to construct the warning event). For each node
  * We check the location (whether its a CallEnter, CallExit) etc. We simultaneously
  keep track of where we are with the execution by pushing CallStack when we see a
  CallExit (keep in mind that everything is happening in reverse!), popping it
  when we find a CallEnter, compacting them into a single PathDiagnosticCallEvent.

void f() {
  bar();
}

void g() {
  f();
  error(); // warning
}

=== The bug path ===

(root) -> f's CallEnter -> bar() -> f's CallExit -> (error node)

=== Constructed report ===

  f's CallEnter -> bar() -> f's CallExit
           ^               /
            \             V
(root) --->  f's CallEvent --> (error node)

  * We also keep track of different PathPieces different location contexts
  * (CallEvent::path in the above example has f's LocationContext, while the
  CallEvent itself is in g's context) in a LocationContextMap object. Construct
  whatever piece, if any, is needed for the note.
  * If we need to generate edges (or arrows) do so. Make sure to also connect
  these pieces with the ones that visitors emitted.
  * Clean up the constructed PathDiagnostic by making arrows nicer, pruning
  function calls, etc.

So I complained about mile long function invocations with seemingly the same
parameters being passed around. This problem, as I see it, a natural candidate
for creating classes and tying them all together.

I tried very hard to make the implementation feel natural, like, rolling off the
tongue. I introduced 2 new classes: PathDiagnosticBuilder (I mean, I kept the
name but changed almost everything in it) contains every contextual information
(owns the bug path, the diagnostics constructed but the visitors, the BugReport
itself, etc) needed for constructing a PathDiagnostic object, and is pretty much
completely immutable. BugReportContruct is the object containing every
non-contextual information (the PathDiagnostic object we're constructing, the
current location in the bug path, the location context map and the call stack I
meantioned earlier), and is passed around all over the place as a single entity
instead of who knows how many parameters.

I tried to used constness, asserts, limiting visibility of fields to my
advantage to clean up the code big time and dramatically improve safety. Also,
whenever I found the code difficult to understand, I added comments and/or
examples.

Here's a complete list of changes and my design philosophy behind it:

* Instead of construcing a ReportInfo object (added by D65379) after finding a
valid bug report, simply return an optional PathDiagnosticBuilder object straight
away. Move findValidReport into the class as a static method. I find
GRBugReporter::generatePathDiagnostics a joy to look at now.
* Rename generatePathDiagnosticForConsumer to generate (maybe not needed, but
felt that way in the moment) and moved it to PathDiagnosticBuilder. If we don't
need to generate diagnostics, bail out straight away, like we always should have.
After that, construct a BugReportConstruct object, leaving the rest of the logic
untouched.
* Move all static methods that would use contextual information into
PathDiagnosticBuilder, reduce their parameter count drastically by simply
passing around a BugReportConstruct object.
* Glance at the code I removed: Could you tell what the original
PathDiagnosticBuilder::LC object was for? It took a gooood long while for me to
realize that nothing really. It is always equal with the LocationContext
associated with our current position in the bug path. Remove it completely.
* The original code contains the following expression quite a bit:
LCM[&PD.getActivePath()], so what does it mean? I said that we collect the
contexts associated with different PathPieces, but why would we ever modify that,
shouldn't it be set? Well, theoretically yes, but in the implementation, the
address of PathDiagnostic::getActivePath doesn't change if we move to an outer,
previously unexplored function. Add both descriptive method names and
explanations to BugReportConstruct to help on this.
* Add plenty of asserts, both for safety and as a poor man's documentation.

Differential Revision: https://reviews.llvm.org/D65484

llvm-svn: 368737
2019-08-13 19:01:33 +00:00
Kristof Umann fc76d8551f [analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it const
When I'm new to a file/codebase, I personally find C++'s strong static type
system to be a great aid. BugReporter.cpp is still painful to read however:
function calls are made with mile long parameter lists, seemingly all of them
taken with a non-const reference/pointer. This patch fixes nothing but this:
make a few things const, and hammer it until it compiles.

Differential Revision: https://reviews.llvm.org/D65382

llvm-svn: 368735
2019-08-13 18:48:08 +00:00