by setting the section of the generated global. This is an
optimization done by the code generator, and the code being
removed didn't handle the case when the string contained an
embedded nul (which the code generator does correctly
handle). This is rdar://7589850
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95003 91177308-0d34-0410-b5e6-96231b3b80d8
deduction failed. Right now there's a very vague diagnostic for most cases
and a good diagnostic for incomplete deduction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94988 91177308-0d34-0410-b5e6-96231b3b80d8
arguments. This both prevents meaningless checks on these arguments and ensures
that they are represented as an expression by the instantiation.
Cleaned up and added standard text to the relevant test case. Also started
adding tests for *rejected* cases. At least one FIXME here where (I think) we
allow something we shouldn't. More to come in the area of rejecting crazy
arguments with decent diagnostics. Suggestions welcome for still better
diagnostics on these errors!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94953 91177308-0d34-0410-b5e6-96231b3b80d8
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94952 91177308-0d34-0410-b5e6-96231b3b80d8
live as long as the ASTUnit. This is useful for clients which want to maintain
pointers to the LangOptions object which ultimately lives in the
CompilerInvocation, although it would be nice to make all of this ownership
stuff more explicit and obvious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94924 91177308-0d34-0410-b5e6-96231b3b80d8
This allows clients to install their own CompilerInvocation object, which is
important for clients that may wish to create references to things like
LangOptions whose lifetime will extend past that of the CompilerInstance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94923 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a really nasty bug in Darwin::getDarwinArchName where we were going
StringRef -> temporary std::string -> StringRef (and return the dead StringRef).
The StringRefs from Triple live as long as the Triple itself, that should be
long enough.
Hopefully 2 of 4 MSVC buildbot failures are gone now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94892 91177308-0d34-0410-b5e6-96231b3b80d8
checking. It passes all existing tests, and the diagnostics have been
refined to provide better range information (we now highlight
individual format specifiers) and more precise wording in the
diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94837 91177308-0d34-0410-b5e6-96231b3b80d8
- Add ConversionSpecifier::consumesDataArgument() as a helper method
to determine if a conversion specifier requires a matching argument.
- Add support for glibc-specific '%m' conversion
- Add an extra callback to HandleNull() for locations within the
format specifier that have a null character
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94834 91177308-0d34-0410-b5e6-96231b3b80d8
previously, we were allowing this to bind to a temporary. Now, we
don't; add test-cases and improve diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94831 91177308-0d34-0410-b5e6-96231b3b80d8
In addition, move ParseFormatString() and FormatStringHandler() from
the clang::analyze_printf to the clang namespace. Hopefully this will
resolve some link errors on Linux.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94794 91177308-0d34-0410-b5e6-96231b3b80d8
to cast a DeclContext down to a specific implementation class.
There are still lots of calls to Decl::castFromDeclContext left, mostly
arising from DeclContext::getParent().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94786 91177308-0d34-0410-b5e6-96231b3b80d8
and fix-it information, so we can see everything in one place. Along
the way, fix a few bugs with deserialization and query of diagnostics
in CIndex.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94768 91177308-0d34-0410-b5e6-96231b3b80d8
so that CIndex can report diagnostics through the normal mechanisms
even when executing Clang in a separate process. This applies both
when performing code completion and when using ASTs as an intermediary
for clang_createTranslationUnitFromSourceFile().
The serialized format is not perfect at the moment, because it does
not encapsulate macro-instantiation information. Instead, it maps all
source locations back to the instantiation location. However, it does
maintain source-range and fix-it information. To get perfect fidelity
from the serialized format would require serializing a large chunk of
the source manager; at present, it isn't clear if this code will live
long enough for that to matter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94740 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94714 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94709 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94702 91177308-0d34-0410-b5e6-96231b3b80d8
now that the "InBytes" part of the name is implied by the return type, rename
it to getDeclAlign().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94681 91177308-0d34-0410-b5e6-96231b3b80d8
reusable and modular API pieces.
Start by pulling the logic for deriving the Cocoa naming convention
into a separate API, header, and source file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94662 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostics in "early" lookups, such as during typename checks and when building
unresolved lookup expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94647 91177308-0d34-0410-b5e6-96231b3b80d8
sync compare_and_swap to match them with gcc.
It also fixes a few incorrect argument defitions.
(fixes radar 7540291).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94607 91177308-0d34-0410-b5e6-96231b3b80d8
(1) libAnalysis is a generic analysis library that can be used by
Sema. It defines the CFG, basic dataflow analysis primitives, and
inexpensive flow-sensitive analyses (e.g. LiveVariables).
(2) libChecker contains the guts of the static analyzer, incuding the
path-sensitive analysis engine and domain-specific checks.
Now any clients that want to use the frontend to build their own tools
don't need to link in the entire static analyzer.
This change exposes various obvious cleanups that can be made to the
layout of files and headers in libChecker. More changes pending. :)
This change also exposed a layering violation between AnalysisContext
and MemRegion. BlockInvocationContext shouldn't explicitly know about
BlockDataRegions. For now I've removed the BlockDataRegion* from
BlockInvocationContext (removing context-sensitivity; although this
wasn't used yet). We need to have a better way to extend
BlockInvocationContext (and any LocationContext) to add
context-sensitivty.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94406 91177308-0d34-0410-b5e6-96231b3b80d8
line -- they may be remapped (fake) files. This is useful for testing parsing
entirely from memory.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94395 91177308-0d34-0410-b5e6-96231b3b80d8
codegen it, so we get 'cannot compile this builtin function yet'
errors, just like we do currently for __builtin_isinf. However,
this should let us parse headers that use it without barfing,
which should help PR6083.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94346 91177308-0d34-0410-b5e6-96231b3b80d8
out. They should all be done later tonight, but if something bad
happens, feel free to revert sooner.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94330 91177308-0d34-0410-b5e6-96231b3b80d8
incomplete type (or a pointer/reference to such).
The causes of this problem are different enough to justify a different "design"
for the diagnostic. Most notably, it doesn't give an operand index:
it's usually pretty obvious which operand is the problem, it adds a lot of
clutter to mention it, and the fix is usually in a different part of the file
anyway.
This is yet another diagnostic that should really have an analogue in the
non-overloaded case --- which should be much easier to write because of
the weaker space constraints.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94303 91177308-0d34-0410-b5e6-96231b3b80d8
have it return a StringRef instead of an integer (to be more VCS
agnostic).
(2) Add getClangFullRepositoryVersion(), which contains an
amalgamation of the repository name and the revision.
(3) Change PCH to only emit the string returned by
getClangFullRepositoryVersion() instead of also emitting the value
of getClangSubversionRevision() (which has been removed). This is
functionally equivalent.
More cleanup to version string generation pending...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94231 91177308-0d34-0410-b5e6-96231b3b80d8
- Added more routines to manipulate/compare source locations and ranges
- Switched clang_getCursor() over to take a CXSourceLocation rather
than file/line/column.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94226 91177308-0d34-0410-b5e6-96231b3b80d8
region of interest (if provided). Implement clang_getCursor() in terms
of this traversal rather than using the Index library; the unified
cursor visitor is more complete, and will be The Way Forward.
Minor other tweaks needed to make this work:
- Extend Preprocessor::getLocForEndOfToken() to accept an offset
from the end, making it easy to move to the last character in the
token (rather than just past the end of the token).
- In Lexer::MeasureTokenLength(), the length of whitespace is zero.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94200 91177308-0d34-0410-b5e6-96231b3b80d8
declarations that have enough source information to make such a walk
useful. This includes walking into variable initializers and enum
constants, the types behind typedefs, etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94124 91177308-0d34-0410-b5e6-96231b3b80d8
ObjCObjectPointerType using the allocator associated with ASTContext.
Not only does this fix a memory leak, but it also makes these arrays
BumpPtrAllocated (in the typical case).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94090 91177308-0d34-0410-b5e6-96231b3b80d8
CallExprs as those edges help cause a n^2 explosion in the number of
destructor calls. Other consumers, such as static analysis, that
would like to have more a more complete CFG can select the inclusion
of those edges as CFG build time.
This also fixes up the two compilation users of CFGs to be tolerant of
having or not having those edges. All catch code is assumed be to
live if we didn't generate the exceptional edges for CallExprs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94074 91177308-0d34-0410-b5e6-96231b3b80d8
Triggers lots of assertions about missing access information; fix them.
Will actually consume this information soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94038 91177308-0d34-0410-b5e6-96231b3b80d8
children of a given cursor, regardless of what kind of cursor it
is. This is a generalization of clang_loadDeclaration and
clang_loadTranslationUnit that will also extent to statements,
expressions, etc.
As proof-of-concept, switched clang_loadDeclaration() from its own
visitor over to an instance of this traversal function internally.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94022 91177308-0d34-0410-b5e6-96231b3b80d8
category implementation when some implementations
are missing in the primary class implementation.
(fixes radar 6505200).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94014 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't entirely satisfactory, as it seems an implementation detail, and
with nothing to do with TargetInfo. Suggestions on where to put this are
welcome.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93974 91177308-0d34-0410-b5e6-96231b3b80d8
Change LookupResult to use UnresolvedSet. Also extract UnresolvedSet into its
own header and make it templated over an inline capacity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93959 91177308-0d34-0410-b5e6-96231b3b80d8
clang_getDeclSource, and clang_getDeclSourceFile; the cursor
equivalents are the way of the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93955 91177308-0d34-0410-b5e6-96231b3b80d8
the root of the conceptual cursor hierarchy (just like we do with
declarations). This will be used when we get to unify
clang_loadTranslationUnit() and clang_loadDeclaration() into something
more generally useful.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93954 91177308-0d34-0410-b5e6-96231b3b80d8
and CXCursor_EnumConstantRef; they've been subsumed by expression
references, which do a much nicer job.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93947 91177308-0d34-0410-b5e6-96231b3b80d8
statements, moving some of the more unnatural kinds of references
(VarRef, EnumConstantRef, etc.) over to the expressions. We can now
poke at arbitrary expressions and statements with, e.g.,
clang_getCursor() and get back useful information (e.g., source
ranges).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93946 91177308-0d34-0410-b5e6-96231b3b80d8
API. This is a catch-all for any declaration known to Clang but not
specifically part of the CIndex API. We'll use the same approach with
expressions, statements, references, etc., as needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93924 91177308-0d34-0410-b5e6-96231b3b80d8