| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
enabled.
llvm-svn: 220849
|
|
|
|
|
|
|
|
| |
off by default, issue a warning if %s directive is used in
certain CF/NS formatting APIs, to assist user in deprecating
use of such %s in these APIs. rdar://18182443
llvm-svn: 217467
|
|
|
|
|
|
|
| |
to +initilize as this results in an extra call
to this method. rdar://16628028
llvm-svn: 216271
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
| |
llvm-svn: 208280
|
|
|
|
| |
llvm-svn: 204196
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for
other languages, error messages and metadata (and hence debug info) should refer
to the half-precision floating point as "__fp16" instead of "half" when
compiling for non-OpenCL languages. This patch creates a new printing policy for
half in a similar manner to what is done for bool and wchar_t.
Differential Revision: http://llvm-reviews.chandlerc.com/D2952
llvm-svn: 204164
|
|
|
|
|
|
| |
class.
llvm-svn: 203537
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
llvm-svn: 199209
|
|
|
|
|
|
|
| |
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
|
|
|
|
|
|
|
|
| |
raw_ostream, and started using it in places it made sense.
No functional changes intended, just API cleanliness.
llvm-svn: 198428
|
|
|
|
|
|
|
| |
methods, infer their self's type as their result type.
// rdar://15145218
llvm-svn: 192377
|
|
|
|
|
|
|
|
| |
'default' methods in Foundation does not
infer 'instancetype' for methods' result type.
// rdar://15145218
llvm-svn: 192129
|
|
|
|
|
|
|
|
| |
'instancetype' for known family of methods
with related result type; such as 'init'
methods. // rdar://14987948
llvm-svn: 190956
|
|
|
|
| |
llvm-svn: 189592
|
|
|
|
|
|
| |
methods which can be migrated to instancetype.
llvm-svn: 187672
|
|
|
|
|
|
| |
in my previous patch which was reverted in r187657
llvm-svn: 187661
|
|
|
|
|
|
| |
buildbot.
llvm-svn: 187657
|
|
|
|
|
|
| |
Also removed check for "NS" prefix for class name.
llvm-svn: 187655
|
|
|
|
|
|
|
|
|
|
| |
with certain prefix selector matching their class names' suffix."
This reverts commit r187626.
It is breaking the bots.
llvm-svn: 187634
|
|
|
|
|
|
|
| |
for mehods with certain prefix selector matching their class names'
suffix.
llvm-svn: 187626
|
|
|
|
|
|
|
|
| |
Expose static type of init/alloc/retain with
instance type as well. Ad-hoc cases are coming
next.
llvm-svn: 187068
|
|
|
|
|
|
| |
instancetype migration.
llvm-svn: 187000
|
|
|
|
|
|
|
| |
which are candidate for migrating to
'instancetype'. wip.
llvm-svn: 186981
|
|
|
|
|
|
|
|
| |
- reduce default buffer size to 64, which will still be large enough to
hold any property names found in the wild.
- get rid of the /*static*/ comments.
llvm-svn: 183697
|
|
|
|
|
|
|
|
|
|
| |
- factor the name construction part out from constructSetterName
- rename constructSetterName to the more appropriate constructSetterSelector
no functionality change intended.
rdar://problem/14035789
llvm-svn: 183582
|
|
|
|
|
|
|
|
|
| |
Typo correction for an unqualified name needs to walk through all of the identifier tables of all modules.
When we have a global index, just walk its identifier table only.
rdar://13425732
llvm-svn: 179730
|
|
|
|
|
|
| |
These are causing assertions on some MSVC builds.
llvm-svn: 174805
|
|
|
|
|
|
|
| |
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
llvm-svn: 174768
|
|
|
|
|
|
| |
nearby 'C++0x' comments.
llvm-svn: 171372
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
| |
latter is rather a mess to type.
llvm-svn: 169919
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
| |
llvm-svn: 167694
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latest macro definition. Needs more work.
Summary: Passes all tests (+ the new one with code completion), but needs a thorough review in part related to modules.
Reviewers: doug.gregor
Reviewed By: alexfh
CC: cfe-commits, rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D41
llvm-svn: 164610
|
|
|
|
| |
llvm-svn: 163221
|
|
|
|
| |
llvm-svn: 161660
|
|
|
|
| |
llvm-svn: 160663
|
|
|
|
|
|
| |
way to disable keywords under Microsoft mode.
llvm-svn: 160612
|
|
|
|
| |
llvm-svn: 158548
|
|
|
|
|
|
|
|
| |
that bridging between the two is free. Saves ~4k of code size,
although I don't see any measurable performance difference
(unfortunately).
llvm-svn: 156187
|
|
|
|
| |
llvm-svn: 152547
|
|
|
|
|
|
|
|
|
| |
IndentifierTable::get() and into IdentifierTable's constructor.
This gets a 0.7% reducing on lexing time for Cocoa.h, and
about the same for PCH generation.
llvm-svn: 151854
|
|
|
|
|
|
|
|
| |
commit to a particular syntax for modules,
and don't have time to push it forward in the near future.
llvm-svn: 151841
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
|
|
|
|
| |
include.
Fix all the transitive include users.
llvm-svn: 149783
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
| |
llvm-svn: 147469
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.
Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.
llvm-svn: 147467
|
|
|
|
|
|
|
| |
to make a macro public (the default for headers) or private,
respectively.
llvm-svn: 147455
|