Enable incremental parsing by the Preprocessor,
where more code can be provided after an EOF.
It mainly prevents the tearing down of the topmost lexer.
To be used like this:
PP.enableIncrementalProcessing();
while (getMoreSource()) {
while (Parser.ParseTopLevelDecl(ADecl)) {...}
}
PP.enableIncrementalProcessing(false);
llvm-svn: 152914
Reintroduce lazy name lookup table building, ensuring that the lazy building step
produces the same lookup table that would be built by the eager step.
Avoid building a lookup table for the translation unit outside C++, even in cases
where we can't recover the contents of the table from the declaration chain on
the translation unit, since we're not going to perform qualified lookup into it
anyway. Continue to support lazily building such lookup tables for now, though,
since ASTMerge uses them.
In my tests, this performs very similarly to ToT with r152608 backed out, for C,
Obj-C and C++, and does not suffer from PR10447.
llvm-svn: 152905
The only use of AggExprVisitor was in #if 0 code (the analyzer's incomplete C++ support), so there is no actual behavioral change anyway.
llvm-svn: 152856
BugVisitor DiagnosticPieces.
When checkers create a DiagnosticPieceEvent, they can supply an extra
string, which will be concatenated with the call exit message for every
call on the stack between the diagnostic event and the final bug report.
(This is a simple version, which could be/will be further enhanced.)
For example, this is used in Malloc checker to produce the ",
which allocated memory" in the following example:
static char *malloc_wrapper() { // 2. Entered call from 'use'
return malloc(12); // 3. Memory is allocated
}
void use() {
char *v;
v = malloc_wrapper(); // 1. Calling 'malloc_wrappers'
// 4. Returning from 'malloc_wrapper', which allocated memory
} // 5. Memory is never released; potential
memory leak
llvm-svn: 152837
-When printing location avoid printing the filename if it is
same as the main file, not just if it has '.h' extension.
-Make sure we allocate enough bytes for storing as string a
huge line number.
llvm-svn: 152821
This allows us to handle extreme cases of chained binary operators without causing stack
overflow.
The binary operators that are handled with the data recursive evaluator are
comma, logical, or operators that have operands with integral or enumeration type.
Part of rdar://10941790.
llvm-svn: 152819
The functions memccpy, strdup, strndup, strlcat, and strlcpy should also have
object size checking support. Of course, this is only good if the C library also
supports these functions.
<rdar://problem/10528974>
llvm-svn: 152789
Err on the side of brevity and rename (while providing aliases for the original
name) -Wbool-conversions, -Wint-conversions, and -Wvector-conversions for
consistency with constant, literal, string, and sign conversion warnings. And
name the diagnostic groups explicitly while I'm here rather than rewriting the
string in the groups and sema td files.
Curiously, vector-conversion is not under -Wconversion. Perhaps it should be.
llvm-svn: 152776
breaking bootstrap. No test yet: it's quite hard to tickle the failure case.
The specific testcase for this wouldn't be useful for testing anything more
general than a reintroduction of this precise bug in any case.
llvm-svn: 152775
Original commit message:
Provide -Wnull-conversion separately from -Wconversion.
Like GCC, provide a NULL conversion to non-pointer conversion as a separate
flag, on by default. GCC's flag is "conversion-null" which we provide for
cross compatibility, but in the interests of consistency (with
-Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called
-Wnull-conversion.
Patch by Lubos Lunak.
Review feedback by myself, Chandler Carruth, and Chad Rosier.
llvm-svn: 152774
locations for diagnostics we're not going to emit, and don't track the subobject
designator outside C++11 (since we're not going to use it anyway).
This seems to give about a 0.5% speedup on 403.gcc/combine.c, but the results
were sufficiently noisy that I can't reject the null hypothesis.
llvm-svn: 152761
-fno-inline-functions.
This behaves much like -fno-inline in gcc, but based on a discussion with
Daniel it was decided that -fno-inline-functions should subsume -fno-inline.
Please speak up if you object. The -fno-inline flag remains ignored.
Final part of rdar://10972766
llvm-svn: 152754
scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.
llvm-svn: 152750
Like GCC, provide a NULL conversion to non-pointer conversion as a separate
flag, on by default. GCC's flag is "conversion-null" which we provide for
cross compatibility, but in the interests of consistency (with
-Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called
-Wnull-conversion.
Patch by Lubos Lunak.
Review feedback by myself, Chandler Carruth, and Chad Rosier.
llvm-svn: 152745
- This may seem superflous, but actually this allows the optimizer to more
easily eliminate the isActive() checks needed by the SemaDiagnosticBuilder
and DiagnosticBuilder dtors. And by more easily, I mean the current LLVM is
actually able to do one and not the other. :)
This is good for another 20k code size reduction.
llvm-svn: 152709
- As with DiagnosticBuilder, it is very important that SemaDiagnosticBuilder be
completely inline to ensure that the compiler can rip it apart and sink it to
registers.
This is good for another 30k reduction in code size.
llvm-svn: 152708
function templates as well.
A future commit will mangle the added name with the template args
like classes are mangled.
Fixes rdar://10986010
llvm-svn: 152683
"struct{template struct{" would fail an assertion.
This assertion failure seems to have gone away somewhere along the line so
here's a test to make sure we don't regress. We still accept some very weird
explicit template 'instantiations' ("template int;", anyone) but at least we're
not asserting/crashing here.
llvm-svn: 152681
- This is much more important than it appears at first glance...
The intended design of DiagnosticBuilder was that it never escape and that all
its members would get lowered to registers by the compiler. By fixing Emit here,
the compiler can completely eliminate the DiagnosticBuilder object and never
need to push those registers back into it.
Unfortunately, Sema has broken DiagnosticBuilder in other ways (by introducing
SemaDiagnosticBuilder), so we don't get the fill impact of this, but it is still
good for 30k reduction in code size. I'll work on fixing the
SemaDiagnosticBuilder problems next.
llvm-svn: 152669
Previously, only diagnostics thrown by the cc1 process were
actually honoring the diagnostic options given on the command line,
like -Werror.
Reuse the existing code in Frontend currently used for cc1,
adjusting it to not interpret -Wl, linker flags as warnings.
Also fix a faulty test exposed by this change.
It wasn't actually testing anything, and was giving this warning:
clang-3: warning: argument unused during compilation: '-verify'
Which -Werror didn't turn into an error because it was output
by the driver, not the cc1 process, and diagnostic options
weren't parsed by the driver. And you couldn't see the warning
when running the test suite.
Fixes PR12181.
Patch by Dylan Noblesmith <nobled@dreamwidth.org>.
llvm-svn: 152660
inlining to be the reverse of their declaration.
This optimizes running time under inlining up to 20% since we do not
re-analyze the utility functions which are usually defined first in the
translation unit if they have already been analyzed while inlined into
the root functions.
llvm-svn: 152653
BFS should give slightly better performance. Ex: Suppose, we have two
roots R1 and R2. A callee function C is reachable through both. However,
C is not inlined when analyzing R1 due to inline stack depth limit. With
DFS, C will be analyzed as top level even though it would be analyzed as
inlined through R2. On the other hand, BFS could avoid analyzing C as
top level.
llvm-svn: 152652
AnalysisConsumer.
As a result:
- We now analyze the C++ methods which are defined within the
class body. These were completely skipped before.
- Ensure that AST checkers are called on functions in the
order they are defined in the Translation unit.
llvm-svn: 152650
by ~%.3/~100k in my build -- simply by eliminating the horrible code bloat coming
from the .clear() of the SmallVector<FixItHint>, which does a std::~string, etc.
- My understanding is we don't ever emit arbitrary numbers of fixits, so I just
moved us to using a statically sized array like we do for arguments and
ranges.
llvm-svn: 152639
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
ObjCInterfaceDecl::getReferencedProtocols(), because the iterators are safe to use
even if the caller did not check that the interface is a definition.
llvm-svn: 152597
the diagnostic for assigning to a copied block capture. This has
the pleasant side-effect of letting us special-case the diagnostic
for assigning to a copied lambda capture as well, without introducing
a new non-modifiable enumerator for it.
llvm-svn: 152593
FYI,
On VS10, %INCLUDE% contains;
(VS10)\VC\INCLUDE
(VS10)\VC\ATLMFC\INCLUDE
(SDK70A)\include
On VS11,
(VS11)\VC\INCLUDE
(VS11)\VC\ATLMFC\INCLUDE
(SDK80)\include\shared
(SDK80)\include\um
(SDK80)\include\winrt
FIXME: It may be enabled also on mingw.
llvm-svn: 152589
The LIBRARY_PATH environment variable should be honored by clang. Have the
driver pass the directories to the linker.
<rdar://problem/9743567> and PR10296.
llvm-svn: 152578
functions that includes an explicit template argument list, perform
an inner deduction against each of the function templates in that list
and, if successful, use the result of that deduction for the outer
template argument deduction. Fixes PR11713.
llvm-svn: 152575
serialized
-Don't add methods of invalid objc containers to the global method pool.
This protects us from trying to serialize a method whose container was not
serialized.
Part of rdar://11007039.
llvm-svn: 152566
being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
llvm-svn: 152551
defined here, but not semantically, so
new struct S {};
is always ill-formed, even if there is a struct S in scope.
We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.
llvm-svn: 152549
To link with -static -lclang, linker tries to seek not libclang.so, clang.dll nor libclang.dll.a, but libclang.a. USEDLIBS should have correct dependencies for -static.
(In contrast, USEDLIBS=libclang.so might be enough w/o -static)
FYI, cygwin build (in buildbot) is using -static, due to avoiding weirdness of extremely slower startup lag of clang.exe.
llvm-svn: 152539
Renamed methods caseBegin, caseEnd and caseDefault with case_begin, case_end, and case_default.
Added some notes relative to case iterators.
llvm-svn: 152533
structural comparison of non-dependent types. Otherwise, we end up
rejecting cases where the non-dependent types don't match due to
qualifiers in, e.g., a pointee type. Fixes PR12132.
llvm-svn: 152529
access expression is the start of a template-id, ignore function
templates found in the context of the entire postfix-expression. Fixes
PR11856.
llvm-svn: 152520
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
enum is scoped or not, which is not relevant here. Instead, phrase the loop in
the same terms that the standard uses, instead of this awkward set of
conditions that is *nearly* equal.
llvm-svn: 152489
Before r151307 this part worked without compiler errors but now it only verifies
that our handling of irregular pragmas is broken compared to gcc, it has no
practical usefulness; it creates invalid structs that cannot be used for 'offsetof' testing.
If we later decide to handle irregular pragmas without compiler errors we can
put back this part.
llvm-svn: 152480
we correctly emit loads of BlockDeclRefExprs even when they
don't qualify as ODR-uses. I think I'm adequately convinced
that BlockDeclRefExpr can die.
llvm-svn: 152479
as aborted, but didn't treat such cases as sinks in the ExplodedGraph.
Along the way, add basic support for CXXCatchStmt, expanding the set of code we actually analyze (hopefully correctly).
Fixes: <rdar://problem/10892489>
llvm-svn: 152468
- We do this when it is easy to determine that the backend will pass them on
the stack properly by itself.
Currently LLVM codegen is really bad in some cases with byval, for example, on
the test case here (which is derived from Sema code, which likes to pass
SourceLocations around)::
struct s47 { unsigned a; };
void f47(int,int,int,int,int,int,struct s47);
void test47(int a, struct s47 b) { f47(a, a, a, a, a, a, b); }
we used to emit code like this::
...
movl %esi, -8(%rbp)
movl -8(%rbp), %ecx
movl %ecx, (%rsp)
...
to handle moving the struct onto the stack, which is just appalling.
Now we generate::
movl %esi, (%rsp)
which seems better, no?
llvm-svn: 152462
copy-construction, which Daniel Dunbar reports as giving a 0.75% speedup on
403.gcc/combine.c. The performance differences on my constexpr torture tests
are below the noise floor.
llvm-svn: 152455
basic source character set in C++98. Add -Wc++98-compat diagnostics for same in
literals in C++11. Extend such support to cover string literals as well as
character literals, and mark N2170 as done.
This seems too minor to warrant a release note to me. Let me know if you disagree.
llvm-svn: 152444
We do not reanalyze a function, which has already been analyzed as an
inlined callee. As per PRELIMINARY testing, this gives over
50% run time reduction on some benchmarks without decreasing of the
number of bugs found.
Turning the mode on by default.
llvm-svn: 152440
LLVM_READONLY.", getTypeInfo() is totally not READONLY, which I should have
probably noticed given that I made it so mere hours ago. Oops.
llvm-svn: 152434
When an error made a record member invalid, the record would stay as "isBeingDefined" and
not "completeDefinition". Even easily recoverable errors ended up propagating records in
such "beingDefined" state, for example:
struct A {
~A() const; // expected-error {{'const' qualifier is not allowed on a destructor}}
};
struct B : A {}; // A & B would stay as "not complete definition" and "being defined".
This weird state was impending lookups in the records and hitting assertion in the ASTWriter.
Part of rdar://11007039
llvm-svn: 152432
- The theory here is that we have these functions sprinkled in all over the
place. This should allow the optimizer to at least realize it can still do
load CSE across these calls.
- I blindly marked all instances as such, even though the optimizer can infer
this attribute in some instances (some of the inline ones) as that was easier
and also, when given the choice between thinking and not thinking, I prefer
the latter.
You might think this is mere frivolity, but actually this is good for a .7 -
1.1% speedup on 403.gcc/combine.c, JSC/Interpreter.cpp,
OGF/NSBezierPath-OAExtensions.m.
llvm-svn: 152426
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
- getSourceRange() can be very expensive, we should try to avoid it if at all possible.
In conjunction with the previous commit I measured a ~2% speedup on 403.gcc/combine.c and a 3% speedup on OmniGroupFrameworks/NSBezierPath-OAExtensions.m.
llvm-svn: 152411
- There are probably a lot more of these worth adding, but these are a start at hitting some of the exprs for which getSourceRange().getBegin() is a poor substitute for getLocStart().
llvm-svn: 152410
This renames the -Wformat-non-standard flag to -Wformat-non-iso,
rewords the current warnings a bit (pointing out that a format string
is not supported by ISO C rather than being "non standard"),
and adds a warning about positional arguments.
llvm-svn: 152403
- On -emit-llvm-only of 403.gcc/combine.c, for example, we make 160k calls to
getTypeInfo but only ever deal with 680 some distinct types.
I saw these speedups (user time):
403.gcc/combine.c -- 3.1%
OmniGroupFrameworks/NSBezierPath-OAExtensions.m -- 3.6%
JavaScriptCore/Interpreter.cpp -- 1.4%
which seems pretty sweet.
I ran some histograms on those compiles and we end up doing a ton of
getTypeInfo() on 'char' and 'int'. I tried splitting out a fast path for builtin
types, but this wasn't a win. Still kinda seems like we could be doing better
here.
llvm-svn: 152377
- This function is not at all free; pass it around along some hot paths instead
of recomputing it deep inside various VarDecl methods.
llvm-svn: 152363
Essentially, a bug centers around a story for various symbols and regions. We should only include
the path diagnostic events that relate to those symbols and regions.
The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
can be modified at BugReport creation or by BugReporterVisitors.
This patch reduces the diagnostics emitted in several of our test cases. I've vetted these as
having desired behavior. The only regression is a missing null check diagnostic for the return
value of realloc() in test/Analysis/malloc-plist.c. This will require some investigation to fix,
and I have added a FIXME to the test case.
llvm-svn: 152361
analyzed.
The CallGraph is used when inlining is on, which is the current default.
This alone does not bring any performance improvement. It's a
stepping stone for the upcoming optimization in which we do not
re-analyze a function that has already been analyzed while inlined in
other functions. Using the call graph makes it easier to play with
the order of functions to minimize redundant analyzes.
llvm-svn: 152352
for a few kinds of error. Specifically:
Since we're after translation phase 6, the "" token might be formed by multiple
source-level string literals. Checking the token width is not a correct way of
detecting empty string literals, due to escaped newlines. Diagnose and recover
from a missing space between "" and suffix, and from string literals other than
"", which are followed by a suffix.
llvm-svn: 152348
first codepoint! Also, don't reject empty raw string literals for spurious
"encoding" issues. Also, don't rely on undefined behavior in ConvertUTF.c.
llvm-svn: 152344
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136146.html
Implemented CaseIterator and it solves almost all described issues: we don't need to mix operand/case/successor indexing anymore. Base iterator class is implemented as a template since it may be initialized either from "const SwitchInst*" or from "SwitchInst*".
ConstCaseIt is just a read-only iterator.
CaseIt is read-write iterator; it allows to change case successor and case value.
Usage of iterator allows totally remove resolveXXXX methods. All indexing convertions done automatically inside the iterator's getters.
Main way of iterator usage looks like this:
SwitchInst *SI = ... // intialize it somehow
for (SwitchInst::CaseIt i = SI->caseBegin(), e = SI->caseEnd(); i != e; ++i) {
BasicBlock *BB = i.getCaseSuccessor();
ConstantInt *V = i.getCaseValue();
// Do something.
}
If you want to convert case number to TerminatorInst successor index, just use getSuccessorIndex iterator's method.
If you want initialize iterator from TerminatorInst successor index, use CaseIt::fromSuccessorIndex(...) method.
There are also related changes in llvm-clients: klee and clang.
llvm-svn: 152298
starting with an underscore is ill-formed.
Since this rule rejects programs that were using <inttypes.h>'s macros, recover
from this error by treating the ud-suffix as a separate preprocessing-token,
with a DefaultError ExtWarn. The approach of treating such cases as two tokens
is under discussion for standardization, but is in any case a conforming
extension and allows existing codebases to keep building while the committee
makes up its mind.
Reword the warning on the definition of literal operators not starting with
underscores (which are, strangely, legal) to more explicitly state that such
operators can't be called by literals. Remove the special-case diagnostic for
hexfloats, since it was both triggering in the wrong cases and incorrect.
llvm-svn: 152287
paren/brace/bracket tracking (the Consume* functions already did it),
removing the use of ConsumeAnyToken(), and moving the hot paths inline
with the error paths out-of-line.
llvm-svn: 152274
The final graph contains a single root node, which is a parent of all externally available functions(and 'main'). As well as a list of Parentless/Unreachable functions, which are either truly unreachable or are unreachable due to our analyses imprecision.
The analyzer checkers debug.DumpCallGraph or debug.ViewGraph can be used to look at the produced graph.
Currently, the graph is not very precise, for example, it entirely skips edges resulted from ObjC method calls.
llvm-svn: 152272
Nick Lewycky