Summary:
This makes it possible to share code between lib/AST/MicrosoftCXXABI.cpp
and lib/CodeGen/MicrosoftCXXABI.cpp. No functionality change.
Also adds comments about the layout of the member pointer structs as I
currently understand them.
Reviewers: rjmccall
CC: timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D590
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178548 91177308-0d34-0410-b5e6-96231b3b80d8
Basically we have always special-cased the top-level statement of an
unwrapped line (the one with ParenLevel == 0) and that lead to several
inconsistencies. All added tests were formatted in a strange way, for
example:
Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()) {
}
After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()) {
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178542 91177308-0d34-0410-b5e6-96231b3b80d8
variable in a C99 inline (but not static-inline or extern-inline)
function definition.
The standard doesn't actually say that this doesn't apply to
"extern inline" definitions, but that seems like a useful extension,
and it at least doesn't have the obvious flaw that a static
mutable variable in an externally-available definition does.
rdar://13535367
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178520 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor invalidateRegions to take SVals instead of Regions as input and teach RegionStore
about processing LazyCompoundVal as a top-level “escaping” value.
This addresses several false positives that get triggered by the NewDelete checker, but the
underlying issue is reproducible with other checkers as well (for example, MallocChecker).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178518 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure we do not generate line info for debugging-related frame setup.
Follow-up to r178361 / rdar://problem/12767564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178517 91177308-0d34-0410-b5e6-96231b3b80d8
This is a heuristic to make up for the fact that the analyzer doesn't
model C++ containers very well. One example is modeling that
'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be
nice to model this explicitly, but for now it just results in a lot of
false positives.
The actual heuristic checks if the base type has a member named 'begin' or
'iterator'. If so, we treat the constructors and destructors of that type
as opaque, rather than inlining them.
This is intended to drastically reduce the number of false positives
reported with experimental destructor support turned on. We can tweak the
heuristic in the future, but we'd rather err on the side of false negatives
for now.
<rdar://problem/13497258>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178516 91177308-0d34-0410-b5e6-96231b3b80d8
Certain properties of a function can determine ahead of time whether or not
the function is inlineable, such as its kind, its signature, or its
location. We can cache this value in the FunctionSummaries map to avoid
rechecking these static properties for every call.
Note that the analyzer may still decide not to inline a specific call to
a function because of the particular dynamic properties of the call along
the current path.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178515 91177308-0d34-0410-b5e6-96231b3b80d8
The summaries lasted for the lifetime of the map anyway; no reason to
include an extra allocation.
Also, use SmallBitVector instead of BitVector to track the visited basic
blocks -- most functions will have less than 64 basic blocks -- and
use bitfields for the other fields to reduce the size of the structure.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178514 91177308-0d34-0410-b5e6-96231b3b80d8
This is controlled by the 'suppress-c++-stdlib' analyzer-config flag.
It is currently off by default.
This is more suppression than we'd like to do, since obviously there can
be user-caused issues within 'std', but it gives us the option to wield
a large hammer to suppress false positives the user likely can't work
around.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178513 91177308-0d34-0410-b5e6-96231b3b80d8
specifier for an enumeration. Also fix a crash-on-invalid if a non-dependent
name specifier is used to declare an enum template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178502 91177308-0d34-0410-b5e6-96231b3b80d8
when we actually end a lexical block.
* Added new test for line table / block cleanup.
* Follow-up to r177819 / rdar://problem/13115369
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178490 91177308-0d34-0410-b5e6-96231b3b80d8
visible. There's a lot of potential badness in how we're modelling
these things, but getting this much correct is reasonably easy.
rdar://13535367
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178488 91177308-0d34-0410-b5e6-96231b3b80d8
gcc provides -mfprnd and -mno-fprnd for controlling the fprnd target
feature; support these options as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178414 91177308-0d34-0410-b5e6-96231b3b80d8
Post-Inc can occur as a binary call (the infamous dummy int argument), but it's
not really a binary operator.
Fixes PR15628.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178412 91177308-0d34-0410-b5e6-96231b3b80d8
Evaluating a C++ new expression now includes generating an intermediate
ExplodedNode, and this node could very well represent a previously-
reachable state in the ExplodedGraph. If so, we can short-circuit the
rest of the evaluation.
Caught by the assertion a few lines later.
<rdar://problem/13510065>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178401 91177308-0d34-0410-b5e6-96231b3b80d8