Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251041 91177308-0d34-0410-b5e6-96231b3b80d8
* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target specific preprocessor macros.
* pulls in target-specific builtins from aux target.
* sets appropriate host or device attribute on builtins.
Differential Revision: http://reviews.llvm.org/D12917
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248299 91177308-0d34-0410-b5e6-96231b3b80d8
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.
Thanks to Richard Smith for reviewing this patch!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242499 91177308-0d34-0410-b5e6-96231b3b80d8
A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.
The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.
rdar://problem/20091852
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240225 91177308-0d34-0410-b5e6-96231b3b80d8
in-progress implementation of the Concepts TS. The recommended feature
test macro __cpp_experimental_concepts is set to 1 (as opposed to
201501) to indicate that the feature is enabled, but the
implementation is incomplete.
The link to the Concepts TS in cxx_status is updated to refer to the
PDTS (N4377). Additional changes related to __has_feature and
__has_extension are to follow in a later change.
Relevant tests include:
test/Lexer/cxx-features.cpp
The test file is updated with testing of the C++14 + Concepts TS mode.
The expected behaviour is the same as that of the C++14 modes except
for the case of __cpp_experimental_concepts."
- Hubert Tong.
Being committed for Hubert (as per his understanding with Richard Smith) as we start work on the concepts-ts following our preliminary strategy session earlier today.
The patch is tiny and seems quite standard.
Thanks Hubert!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237982 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).
The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.
There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).
While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.
Differential Revision: http://reviews.llvm.org/D9333
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237299 91177308-0d34-0410-b5e6-96231b3b80d8
Before C11 there was only the DECIMAL_DIG definition. As of C11, we now
have one definition per floating point type (e.g. DBL_DECIMAL_DIG).
Change the existing code to define the new versions. To remain backward
compatible, define __DECIMAL_DIG__ as __LDBL_DECIMAL_DIG__.
Also update the tests. It seems that some of the existing test vectors
were incorrect. Change all tests for __DECIMAL_DIG__ to expect
__LDBL_DECIMAL_DIG__. Add tests for *_DECIMAL_DIG for FreeBSD/amd64, as
I happen to have such a system laying around. I've validated that the
values are in sync with <float.h>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230207 91177308-0d34-0410-b5e6-96231b3b80d8
Partially revert r223927 because LLVM gained support for 128-bit integers
in r227089. Modify and keep the tests that verify the definition of the
macro __SIZEOF_INT128__ for MIPS64 BE & LE in the preprocessor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228918 91177308-0d34-0410-b5e6-96231b3b80d8
For compatibility with GCC (and because it's generally helpful information
otherwise inaccessible to the preprocessor). This appears to be canonically the
alignment of max_align_t (e.g. on i386, __BIGGEST_ALIGNMENT__ is 4 even though
vector types will be given greater alignment).
Patch mostly by Mats Petersson
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228367 91177308-0d34-0410-b5e6-96231b3b80d8
This is a temporary workaround while MIPS64 has not yet fully supported
128-bit integers. But declaration of int128 type is necessary even though
`__SIZEOF_INT128__` is undefined because c++ standard header files like
`limits` throw error message if `__int128` is not available.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D6402
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223927 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Allow CUDA host device functions with two code paths using __CUDA_ARCH__
to differentiate between code path being compiled.
For example:
__host__ __device__ void host_device_function(void) {
#ifdef __CUDA_ARCH__
device_only_function();
#else
host_only_function();
#endif
}
Patch by Jacques Pienaar.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D6457
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223271 91177308-0d34-0410-b5e6-96231b3b80d8
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221963 91177308-0d34-0410-b5e6-96231b3b80d8
GCC defines __EXCEPTIONS, regardless of language mode, if -fexceptions
is passed. We should do the same.
This fixes PR21358.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220714 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a flag called -fseh-exceptions that uses the native Windows
.pdata and .xdata unwind mechanism to throw exceptions. The other EH
possibilities are DWARF and SJLJ exceptions.
Patch by Martell Malone!
Reviewed By: asl, rnk
Differential Revision: http://reviews.llvm.org/D3419
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217790 91177308-0d34-0410-b5e6-96231b3b80d8
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215982 91177308-0d34-0410-b5e6-96231b3b80d8
According to the gcc docs, -include uses the current working directory
for the lookup instead of the main source file.
This patch gets rid of NormalizeIncludePath (which relied on an
implementation detail of FileManager / FileEntry for the include path
logic to work), and instead hands the correct lookup information down to
LookupFile.
This will allow us to change the FileEntry's behavior regarding its Name
caching.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215433 91177308-0d34-0410-b5e6-96231b3b80d8
These macros are used as markers for Interface Builder and need to be defined
to empty strings since they have no impact on the code.
Patch by Ted Kremenek.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215259 91177308-0d34-0410-b5e6-96231b3b80d8
constants. Comparing int against a constant of the given type like
UINT8_MAX will otherwise force a promotion to unsigned int, which is
typically not expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213301 91177308-0d34-0410-b5e6-96231b3b80d8
These two functions initialize the source manager and header search objects and
shouldn't be in InitPreprocessor which is concerned with priming the
preprocessor itself and predefining macros.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212434 91177308-0d34-0410-b5e6-96231b3b80d8
If someone on Linux asks for -fms-extensions, there's no reason not to
define the feature test macros that MSVC defines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206413 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r90596 from 2009. Having this macro definition makes Clang
strictly less useful with -fms-extensions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205729 91177308-0d34-0410-b5e6-96231b3b80d8
This commit reverts r201037, it's functionality is not needed given the
definition of std::max_align_t in libcxx circa r201843.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202667 91177308-0d34-0410-b5e6-96231b3b80d8
TargetInfo::getSuitableAlign() was introduced in r146762 and is defined
as alignof(std::max_align_t).
Introduce __ALIGNOF_MAX_ALIGN_T__ which exposes getSuitableAlign() so
that libc++ may take advantage of it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201037 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199209 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of keeping it in amongst the macros, build the declaration at Sema init
the same way we do with other predeclared and builtin types.
In practice this means the declaration is marked implicit and therefore won't
show up as an unwanted user-declared type in tooling which has been a
frequently reported issue (though I haven't been able to cook up a test).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198497 91177308-0d34-0410-b5e6-96231b3b80d8
John McCall