| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 94725
|
| |
|
|
|
|
| |
(Radar 7583971).
llvm-svn: 94724
|
| |
|
|
|
|
|
|
| |
This function will use the format string parsing logic in libAnalysis,
and once it is shown to be better than the current implementation it
will replace AlternateCheckPrintfString() entirely.
llvm-svn: 94721
|
| |
|
|
| |
llvm-svn: 94717
|
| |
|
|
|
|
| |
format string is desired.
llvm-svn: 94715
|
| |
|
|
|
|
|
|
|
| |
diagnostic callback mechanism, so all diagnostics now go through that
callback. Also, eliminate the displayDiagnostics flag to
clang_createIndex(), since it is no longer necessary: the client
determines whether to display diagnostics or not.
llvm-svn: 94714
|
| |
|
|
| |
llvm-svn: 94713
|
| |
|
|
|
|
| |
class's vtable, if any.
llvm-svn: 94712
|
| |
|
|
| |
llvm-svn: 94710
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clients can format diagnostics as they wish rather than having to
parse standard error. All of the important parts of the front end's
diagnostics are exposed: text, severity, location, source ranges, and
fix-its. The diagnostics callback is now available with
clang_createTranslationUnitFromSource() and
clang_createTranslationUnit().
As part of this change, CXSourceLocation and CXSourceRange got one
pointer larger, since we need to hold on to the SourceManager and
LangOptions structures in the source location. This is the minimum
amount of information needed for the functions that operate on source
locations and ranges (as implemented now). Previously we held on to
the ASTContext, but the diagnostics callback can end up with source
locations when there is no ASTContext (or preprocessor).
Still to do:
- Code completion needs to support the diagnostics callback, once we
have the ability to (de-)serialize diagnostics.
- Eliminate the "displayDiagnostics" argument to createIndex; we'll
always pass diagnostics to the callback and let it deal with display.
llvm-svn: 94709
|
| |
|
|
| |
llvm-svn: 94707
|
| |
|
|
|
|
| |
in SemaChecking).
llvm-svn: 94704
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
strings than what we currently have in Sema. This is both an
experiment and a WIP.
The idea is simple: parse the format string incrementally,
constructing a well-structure representation of each format specifier.
Each format specifier is then handed back one-by-one to a client via a
callback. Malformed format strings are also handled with callbacks.
The idea is to separate the parsing of the format string from the
emission of diagnostics. Currently what we have in Sema for handling
format strings is a mongrel of both that is hard to follow and
difficult to modify (I can apply this label since I'm the original
author of that code).
This is in libAnalysis as it is reasonable generic and can potentially
be used both by libSema and libChecker.
Comments welcome.
llvm-svn: 94702
|
| |
|
|
| |
llvm-svn: 94688
|
| |
|
|
| |
llvm-svn: 94685
|
| |
|
|
|
|
| |
CocoaConventions.h.
llvm-svn: 94682
|
| |
|
|
|
|
|
| |
now that the "InBytes" part of the name is implied by the return type, rename
it to getDeclAlign().
llvm-svn: 94681
|
| |
|
|
|
|
| |
less fragile than the old code.
llvm-svn: 94679
|
| |
|
|
| |
llvm-svn: 94678
|
| |
|
|
| |
llvm-svn: 94677
|
| |
|
|
|
|
| |
runtime-specific code is a bit ugly. It would be a good idea to hoist all of the string / protocol uniqueing code up into CGObjCRuntime or CodeGenModule and only handle emitting the original versions in the runtime-specific code.
llvm-svn: 94676
|
| |
|
|
|
|
| |
showed up with a primitive type.
llvm-svn: 94674
|
| |
|
|
|
|
| |
PR6138
llvm-svn: 94669
|
| |
|
|
| |
llvm-svn: 94668
|
| |
|
|
| |
llvm-svn: 94665
|
| |
|
|
| |
llvm-svn: 94663
|
| |
|
|
|
|
|
|
|
| |
reusable and modular API pieces.
Start by pulling the logic for deriving the Cocoa naming convention
into a separate API, header, and source file.
llvm-svn: 94662
|
| |
|
|
| |
llvm-svn: 94661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
sequences, where we would occasionally determine (incorrectly) that
one standard conversion sequence was a proper subset of another when,
in fact, they contained completely incomparable conversions.
This change records the types in each step within a standard
conversion sequence, so that we can check the specific comparison
types to determine when one sequence is a proper subset of the
other. Fixes this testcase (thanks, Anders!), which was distilled from
PR6095 (also thanks to Anders).
llvm-svn: 94660
|
| |
|
|
|
|
| |
using the same framework we use for deprecation warnings.
llvm-svn: 94659
|
| |
|
|
|
|
| |
(This is needed in order to build Qt).
llvm-svn: 94658
|
| |
|
|
| |
llvm-svn: 94657
|
| |
|
|
|
|
| |
be passed indirectly in the 32-bit ABI. Fixes PR6094.
llvm-svn: 94656
|
| |
|
|
| |
llvm-svn: 94655
|
| |
|
|
| |
llvm-svn: 94654
|
| |
|
|
| |
llvm-svn: 94653
|
| |
|
|
| |
llvm-svn: 94652
|
| |
|
|
| |
llvm-svn: 94651
|
| |
|
|
|
|
|
| |
diagnostics in "early" lookups, such as during typename checks and when building
unresolved lookup expressions.
llvm-svn: 94647
|
| |
|
|
|
|
|
|
| |
this will alleviate some confusion about the existence of this feature.
Comments/improvements welcome.
llvm-svn: 94645
|
| |
|
|
| |
llvm-svn: 94644
|
| |
|
|
|
|
| |
defaults when targetting iPhoneOS (blocks, non-fragile ABI, stack protector).
llvm-svn: 94642
|
| |
|
|
| |
llvm-svn: 94641
|
| |
|
|
|
|
| |
versions to match gcc (which is matching linker changes).
llvm-svn: 94640
|
| |
|
|
|
|
| |
information.
llvm-svn: 94639
|
| |
|
|
|
|
| |
just indicating whether the default target should be iPhoneOS.
llvm-svn: 94638
|
| |
|
|
| |
llvm-svn: 94637
|
| |
|
|
| |
llvm-svn: 94636
|
| |
|
|
|
|
|
| |
this should just be part of the tool chain itself once we have eliminated
argument translation.
llvm-svn: 94635
|
| |
|
|
| |
llvm-svn: 94633
|