Objective-C. The @encode'ing of such an enumeration type is the same
as its underlying type. <rdar://problem/5276348>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139297 91177308-0d34-0410-b5e6-96231b3b80d8
'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139275 91177308-0d34-0410-b5e6-96231b3b80d8
keyword. We now handle this keyword in HandleIdentifier, making a note
for ourselves when we've seen the __import_module__ keyword so that
the next lexed token can trigger a module import (if needed). This
greatly simplifies Preprocessor::Lex(), and completely erases the 5.5%
-Eonly slowdown Argiris noted when I originally implemented
__import_module__. Big thanks to Argiris for noting that horrible
regression!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139265 91177308-0d34-0410-b5e6-96231b3b80d8
ctor-initializer, remember to call the Sema action to generate default
ctor-initializers. What a delightful little miscompile. Fixes PR10578
/ <rdar://problem/9877267>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139253 91177308-0d34-0410-b5e6-96231b3b80d8
function. This is really the beginning of the second phase of
refactorings here. The end goal is to have (roughly) three interfaces:
1) Base class to format a single diagnostic suitable for display on the
console.
2) Extension of the base class which also displays a caret diagnostic
suitable for display on the console.
3) An adaptor that implements the DiagnosticClient by delegating to #1
and/or #2 as appropriate.
Once we have these, things like libclang's formatDiagnostic can use #1
and #2 to provide really well formatted (and consistently formatted!)
textual formatting of diagnostics.
Getting there is going to be quite a bit of shuffling. I'm basically
sketching out where the interface boundaries can be drawn for #1 and #2
within the existing classes. That lets me shuffle with a minimum of fuss
and delta. Once that's done, and any of the related interfaces that need
to change are updated, I'll hoist these into separate headers and
re-implement libclang in terms of their interfaces. Long WIP, but
comments at each step welcome. =D
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139228 91177308-0d34-0410-b5e6-96231b3b80d8
CaretDiagnostic. It's completely generic, with nothing to do with the
diagnostic client or info APIs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139227 91177308-0d34-0410-b5e6-96231b3b80d8
a stack array of a magical size with an assert() that we never
overflowed it. That seems incredibly risky. We also have a very nice API
for bundling up a vector we expect to usually have a small size without
loss of functionality or security if the size is excessive.
The fallout is to remove the last pointer+size parameter pair that are
traced through the recursive caret diagnostic emission.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139217 91177308-0d34-0410-b5e6-96231b3b80d8
There are still a few issues which need to be resolved with code generation for atomic load and store, so I'm not converting the places which need those for now.
I'm not entirely sure what to do about __builtin_llvm_memory_barrier: the fence instruction doesn't expose all the possibilities which can be expressed by __builtin_llvm_memory_barrier. I would appreciate hearing from anyone who is using this intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139216 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch in, clang will generate only 37 errors (down from 212) when parsing a typical MFC source file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139210 91177308-0d34-0410-b5e6-96231b3b80d8
a defined interface. This isn't as nice as the previous one, but should
get better as I push through better data types in all these functions.
Also, I'm hoping to pull some aspects of this out into a common routine
(such as tab expansion).
Again, WIP, comments welcome as I'm going through.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139190 91177308-0d34-0410-b5e6-96231b3b80d8
to look through SubstNonTypeTemplateParmExprs. Then, update the IR
generation of CallExprs to actually use CallExpr::getCalleeDecl()
rather than attempting to mimick its behavior (badly).
Fixes <rdar://problem/10063539>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139185 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Caitlin Sadowski
Argyrios Kyrtzidis
Eric Christopher
Abramo Bagnara
David Blaikie
Chad Rosier
Richard Trieu
Kaelyn Uhrain
Peter Collingbourne
James Molloy
Fariborz Jahanian
Chandler Carruth
Eli Friedman
Francois Pichet
Ted Kremenek