| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 189112
|
| |
|
|
| |
llvm-svn: 188134
|
| |
|
|
|
|
| |
fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention...
llvm-svn: 187762
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This unifies the unix and windows versions of FileManager::UniqueDirContainer
and FileManager::UniqueFileContainer by using UniqueID.
We cannot just replace "struct stat" with llvm::sys::fs::file_status, since we
want to be able to construct fake ones, and file_status has different members
on unix and windows.
What the patch does is:
* Record only the information that clang is actually using.
* Use llvm::sys::fs::status instead of stat and fstat.
* Use llvm::sys::fs::UniqueID
* Delete the old windows versions of UniqueDirContainer and
UniqueFileContainer since the "unix" one now works on windows too.
llvm-svn: 187619
|
| |
|
|
| |
llvm-svn: 186647
|
| |
|
|
|
|
|
|
| |
declaration was affected by "@optional"
rdar://14348525.
llvm-svn: 185722
|
| |
|
|
|
|
| |
avoid specifying the vector size unnecessarily.
llvm-svn: 185610
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
llvm-svn: 184763
|
| |
|
|
|
|
|
|
| |
a getter/setter method annotation.
rdar://13764549
llvm-svn: 183242
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or a
function that returns it.
One way to implement this would be to recursively look for local
types. This would look a lot like the linkage computation itself for
types.
To avoid code duplication and utilize the existing linkage cache, this
patch just makes the computation of "type with no linkage but
externally visible because it is from an inline function" part of the
linkage computation itself.
llvm-svn: 182711
|
| |
|
|
| |
llvm-svn: 182682
|
| |
|
|
|
|
| |
Patch by Seth Fowler.
llvm-svn: 182139
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
a FieldDecl from it, and propagate both into the closure type and the
LambdaExpr.
You can't do much useful with them yet -- you can't use them within the body
of the lambda, because we don't have a representation for "the this of the
lambda, not the this of the enclosing context". We also don't have support or a
representation for a nested capture of an init-capture yet, which was intended
to work despite not being allowed by the current standard wording.
llvm-svn: 181985
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
llvm-svn: 181677
|
| |
|
|
|
|
| |
rdar://13680583
llvm-svn: 181352
|
| |
|
|
|
|
|
|
| |
module file where a module object came from.
rdar://13743084
llvm-svn: 180643
|
| |
|
|
|
|
|
|
| |
of CXCursor_CXXThisExpr for C++ code.
rdar://13717006
llvm-svn: 180127
|
| |
|
|
|
|
|
|
| |
given cursor is a variadic function or method.
rdar://13667150
llvm-svn: 179819
|
| |
|
|
|
|
|
|
|
|
| |
Qualifiers' written next to the return and
parameter types in an ObjC method declarations.
rdar://13676977
llvm-svn: 179816
|
| |
|
|
|
|
|
|
| |
written attributes in a property declaration.
rdar://13684512
llvm-svn: 179803
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add CapturedDecl to be the DeclContext for CapturedStmt, and perform semantic
analysis. Currently captures all variables by reference.
TODO: templates
Author: Ben Langmuir <ben.langmuir@intel.com>
Differential Revision: http://llvm-reviews.chandlerc.com/D433
llvm-svn: 179618
|
| |
|
|
|
|
|
|
| |
references thereto.
Patch by Tong Shen!
llvm-svn: 179585
|
| |
|
|
|
|
|
|
| |
out-of-line member functions.
rdar://13535645
llvm-svn: 178911
|
| |
|
|
|
|
| |
null, before using it.
llvm-svn: 178800
|
| |
|
|
|
|
| |
Part of rdar://13296693
llvm-svn: 178162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroDirective's subclasses.
For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
llvm-svn: 178037
|
| |
|
|
| |
llvm-svn: 177705
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.
Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.
llvm-svn: 176975
|
| |
|
|
|
|
|
|
|
|
|
| |
return a value.
Possible values are:
1 : if a parameter was invalid
-1 : if the callback returned CXVisit_Break,
otherwise returns 0.
llvm-svn: 176716
|
| |
|
|
| |
llvm-svn: 176680
|
| |
|
|
|
|
| |
print out the filename.
llvm-svn: 176511
|
| |
|
|
|
|
|
| |
This may need to be fixed more intelligently - I don't have enough context to
be sure what the appropriate fix is right now.
llvm-svn: 175902
|
| |
|
|
|
|
| |
PrintTemplateArgumentList.
llvm-svn: 175894
|
| |
|
|
|
|
| |
did not work as expected.
llvm-svn: 175711
|
| |
|
|
| |
llvm-svn: 175705
|
| |
|
|
| |
llvm-svn: 175701
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
llvm-svn: 175585
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
|
| |
|
|
|
|
|
|
|
| |
is inside a macro argument.
Previously we would give up and not annotate anything in the range.
rdar://11891550
llvm-svn: 175062
|
| |
|
|
|
|
|
|
|
| |
we annotate properly when there is an attribute and not skip type specs
if the attribute is after the declaration.
rdar://13129077
llvm-svn: 174689
|
| |
|
|
| |
llvm-svn: 174606
|
| |
|
|
| |
llvm-svn: 174285
|
| |
|
|
| |
llvm-svn: 174280
|
| |
|
|
|
|
| |
Also migrate all clients from the old API.
llvm-svn: 174263
|
| |
|
|
|
|
| |
Also migrate all clients from the old API.
llvm-svn: 174238
|
| |
|
|
| |
llvm-svn: 174174
|
| |
|
|
| |
llvm-svn: 174173
|
| |
|
|
|
|
|
| |
We are not exposing the pool or string buffers to libclang users, so no need to
maintain a procedural interface.
llvm-svn: 173595
|
| |
|
|
| |
llvm-svn: 173590
|
| |
|
|
| |
llvm-svn: 173589
|