when running the analyzer on real projects. We'll keep the change to
AnalysisManager.cpp in r82198 so that -fobjc-gc analyzes code
correctly in both GC and non-GC modes, although this may emit two
diagnostics for each bug in some cases (a better solution will come
later).
llvm-svn: 82201
pruning of diagnostics that may be emitted multiple times. This is
accomplished by adding FoldingSet profiling support to PathDiagnostic,
and then having BugReporter record what diagnostics have been issued.
This was motived to a serious bug introduced by moving the
'divide-by-zero' checking outside of GRExprEngine into a separate
'Checker' class. When analyzing code using the '-fobjc-gc' option, a
given function would be analyzed twice, but the second time various
"internal checks" would be disabled to avoid emitting multiple
diagnostics (e.g., "null dereference") for the same issue. The
problem is that such checks also effect path pruning and don't just
emit diagnostics. This resulted in an assertion failure involving a
real divide-by-zero in some analyzed code where we would get an
assertion failure in APInt because the 'DivZero' check was disabled
and didn't prune the logic that resulted in the divide-by-zero in the
analyzer.
The implemented solution is somewhat of a hack, and may not perform
extremely well. This will need to be cleaned up over time.
As a regression test, 'misc-ps.m' has been modified so that its tests
are run using -fobjc-gc to test this diagnostic pruning behavior.
llvm-svn: 82198
essence, code completion is triggered by a magic "code completion"
token produced by the lexer [*], which the parser recognizes at
certain points in the grammar. The parser then calls into the Action
object with the appropriate CodeCompletionXXX action.
Sema implements the CodeCompletionXXX callbacks by performing minimal
translation, then forwarding them to a CodeCompletionConsumer
subclass, which uses the results of semantic analysis to provide
code-completion results. At present, only a single, "printing" code
completion consumer is available, for regression testing and
debugging. However, the design is meant to permit other
code-completion consumers.
This initial commit contains two code-completion actions: one for
member access, e.g., "x." or "p->", and one for
nested-name-specifiers, e.g., "std::". More code-completion actions
will follow, along with improved gathering of code-completion results
for the various contexts.
[*] In the current -code-completion-dump testing/debugging mode, the
file is truncated at the completion point and EOF is translated into
"code completion".
llvm-svn: 82166
- Move CMake to using the new test runner.
- Switch Makefiles to use the lit.site.cfg.in template.
- Remove explicit --path arguments, instead this gets written into the site
configuration. This means running lit from the command line should use the
exact same configuration as is used in 'make test', assuming it can find the
site configuration file. You still need to run 'make test' (or the cmake
build target equivalent) at least once.
llvm-svn: 82160
This fixes some bad -O0 codegen and the unnecessary clearing of al on entry to objc_msgSend for most message sends.
<rdar://problem/7102824> [irgen] unnecessary xorb on calls to objc_msgSend on x86_64
llvm-svn: 82118
- Doesn't actually work yet because only module level asm's get correctly marked as externally visible in the PCH.
- Other things like 'clang-cc foo.ast -ast-dump' now work, as well.
llvm-svn: 82107
when we are not instantiating the corresponding "current
instantiation." This happens, e.g., when we are instantiating a
declaration reference that refers into the "current instantiation" but
occurs in a default function argument. The libstdc++ vector default
constructor now instantiates properly.
llvm-svn: 82069
give them the appropriate exception specifications. This,
unfortunately, requires us to maintain and/or implicitly generate
handles to namespace "std" and the class "std::bad_alloc". However,
every other approach I've come up with was more hackish, and this
standard requirement itself is quite the hack.
Fixes PR4829.
llvm-svn: 81939
to pointer function for delete expression. 2)
Treat type conversion function and its 'const' version
as identical in building the visible conversion list.
llvm-svn: 81930
point at the template and print out its template arguments, e.g.,
ambiguous-ovl-print.cpp:5:8: note: candidate function template specialization
[with T = int]
void f(T*, long);
llvm-svn: 81907
Ted Kremenek