| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
places. I've turned this off for the GNU runtimes --- I don't know if
they support weak class import, but it's easy enough for them to opt in.
Also tweak a comment per review by Jordan.
llvm-svn: 158860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
|
|
|
|
|
|
|
| |
caused a crash in an obscure case. On the plus side, it caused me to catch
another bug by inspection.
llvm-svn: 158767
|
|
|
|
|
|
|
|
| |
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
llvm-svn: 158749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this is mostly a structural patch that handles the change from the old
spelling style to the new one. One consequence of this is that all AT_foo_bar
enum values have changed to not be based off of the first spelling, but rather
off of the class name, so they are now AT_FooBar and the like (a straw poll on
IRC showed support for this). Apologies for code churn.
Most attributes have GNU spellings as a temporary solution until everything else
is sorted out (such as a Keyword spelling, which I intend to add if someone else
doesn't beat me to it). This is definitely a WIP.
I've also killed BaseCheckAttr since it was unused, and I had to go through
every attribute anyway.
llvm-svn: 158700
|
|
|
|
|
|
| |
Fixes assertion hit in the preprocessing record. rdar://11426523
llvm-svn: 156557
|
|
|
|
| |
llvm-svn: 155082
|
|
|
|
|
|
| |
return types, from Michel Morin!
llvm-svn: 154428
|
|
|
|
|
|
|
| |
for templates with local template arguments, from Michel Morin! Fixes
PR12337.
llvm-svn: 153983
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
| |
llvm-svn: 152396
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
|
|
|
|
|
|
|
|
|
|
| |
grammar requires a string-literal and not a user-defined-string-literal. The
two constructs are still represented by the same TokenKind, in order to prevent
a combinatorial explosion of different kinds of token. A flag on Token tracks
whether a ud-suffix is present, in order to prevent clients from needing to look
at the token's spelling.
llvm-svn: 152098
|
|
|
|
| |
llvm-svn: 151992
|
|
|
|
| |
llvm-svn: 151809
|
|
|
|
| |
llvm-svn: 151458
|
|
|
|
|
|
| |
likewise for __has_extension). Patch by Jonathan Sauer!
llvm-svn: 151445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
llvm-svn: 151352
|
|
|
|
|
|
|
| |
compiler support for the std::is_trivially_assignable library type
trait.
llvm-svn: 151240
|
|
|
|
| |
llvm-svn: 151231
|
|
|
|
| |
llvm-svn: 150524
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
|
|
| |
// rdar://10770497
llvm-svn: 149565
|
|
|
|
|
|
|
|
|
|
| |
__has_builtin
in an empty file, as we were overwriting the EOF token. Overwriting an arbitrary token
never seems like a good idea in the error case. This fixes a bug reported on the GCC
list :)
llvm-svn: 149397
|
|
|
|
|
|
|
|
| |
when it actually has changed (and not, e.g., when we've simply attached a
deserialized macro definition). Good for ~1.5% reduction in module
file size, mostly in the identifier table.
llvm-svn: 148808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load
- Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function.
- Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it.
Still to do:
- Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg.
- Add a signal fence builtin
- Properly set the fenv state in atomic operations on floating point values
- Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context)
- Fix the many remaining corner cases
llvm-svn: 148242
|
|
|
|
|
|
|
|
|
| |
any language variant), and restrict __has_feature(objc_modules) to
mean that we also have the Objective-C @import syntax. I anticipate
__has_feature(cxx_modules) and/or __has_feature(c_modules) for when we
nail down the module syntax for C/C++.
llvm-svn: 147548
|
|
|
|
| |
llvm-svn: 147482
|
|
|
|
| |
llvm-svn: 147433
|
|
|
|
|
|
|
|
| |
so this patch is surprisingly small.
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
llvm-svn: 147221
|
|
|
|
| |
llvm-svn: 147195
|
|
|
|
|
|
|
|
| |
macro expansion.
rdar://10588825
llvm-svn: 146818
|
|
|
|
|
|
|
| |
a class is marked 'final', from Alberto Ganesh Barbati! Fixes
PR11462.
llvm-svn: 145775
|
|
|
|
|
|
| |
LangOpts.AddressSanitizer instead of CodeGenOpts.AddressSanitizer
llvm-svn: 145054
|
|
|
|
|
|
| |
__has_feature(cxx_unicode_literals), from Michel Morin!
llvm-svn: 143412
|
|
|
|
|
|
| |
functions", from Michel Morin!
llvm-svn: 143411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AST file more lazy, so that we don't eagerly load that information for
all known identifiers each time a new AST file is loaded. The eager
reloading made some sense in the context of precompiled headers, since
very few identifiers were defined before PCH load time. With modules,
however, a huge amount of code can get parsed before we see an
@import, so laziness becomes important here.
The approach taken to make this information lazy is fairly simple:
when we load a new AST file, we mark all of the existing identifiers
as being out-of-date. Whenever we want to access information that may
come from an AST (e.g., whether the identifier has a macro definition,
or what top-level declarations have that name), we check the
out-of-date bit and, if it's set, ask the AST reader to update the
IdentifierInfo from the AST files. The update is a merge, and we now
take care to merge declarations before/after imports with declarations
from multiple imports.
The results of this optimization are fairly dramatic. On a small
application that brings in 14 non-trivial modules, this takes modules
from being > 3x slower than a "perfect" PCH file down to 30% slower
for a full rebuild. A partial rebuild (where the PCH file or modules
can be re-used) is down to 7% slower. Making the PCH file just a
little imperfect (e.g., adding two smallish modules used by a bunch of
.m files that aren't in the PCH file) tips the scales in favor of the
modules approach, with 24% faster partial rebuilds.
This is just a first step; the lazy scheme could possibly be improved
by adding versioning, so we don't search into modules we already
searched. Moreover, we'll need similar lazy schemes for all of the
other lookup data structures, such as DeclContexts.
llvm-svn: 143100
|
|
|
|
| |
llvm-svn: 142423
|
|
|
|
|
|
|
|
| |
This also adds a -Wc++98-compat-pedantic for warning on constructs which would
be diagnosed by -std=c++98 -pedantic (that is, it warns even on C++11 features
which we enable by default, with no warning, in C++98 mode).
llvm-svn: 142034
|
|
|
|
| |
llvm-svn: 142020
|
|
|
|
|
|
| |
warning flag is valid. Fixes <rdar://problem/10263428>.
llvm-svn: 141802
|
|
|
|
| |
llvm-svn: 141012
|
|
|
|
| |
llvm-svn: 140478
|
|
|
|
| |
llvm-svn: 140368
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
| |
llvm-svn: 140288
|
|
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
|
|
|
|
|
|
| |
#include or #import direcctives of framework headers into module
imports of the corresponding framework module.
llvm-svn: 139860
|
|
|
|
|
|
|
| |
Objective-C. The @encode'ing of such an enumeration type is the same
as its underlying type. <rdar://problem/5276348>.
llvm-svn: 139297
|
|
|
|
|
|
|
|
|
|
| |
'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>.
llvm-svn: 139275
|