summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/PPMacroExpansion.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Turn off __has_feature(cxx_rtti) when -fno-rtti-data is presentReid Kleckner2015-08-131-1/+1
| | | | | | | | | | | -fno-rtti-data makes it so that vtables emitted in the current TU lack RTTI data. This means that dynamic_cast usually fails at runtime. Users of the existing cxx_rtti feature expect all of RTTI to work, not just some of it. Chromium bug for context: http://crbug.com/518191 llvm-svn: 244922
* Ignore the "novtable" declspec when not using the Microsoft C++ ABI.Bob Wilson2015-07-201-3/+3
| | | | | | | | | | | | | | Clang used to silently ignore __declspec(novtable). It is implemented now, but leaving the vtable uninitialized does not work when using the Itanium ABI, where the class layout for complex class hierarchies is stored in the vtable. It might be possible to honor the novtable attribute in some simple cases and either report an error or ignore it in more complex situations, but it’s not clear if that would be worthwhile. There is also value in having a simple and predictable behavior, so this changes clang to simply ignore novtable when not using the Microsoft C++ ABI. llvm-svn: 242730
* Add __has_feature(attribute_availability_with_version_underscores).Jordan Rose2015-07-161-0/+1
| | | | | | | | This goes with r218884 from, um, last autumn. rdar://problem/21754114 llvm-svn: 242480
* Implement variance for Objective-C type parameters.Douglas Gregor2015-07-071-0/+1
| | | | | | | | | | | | | | | Introduce co- and contra-variance for Objective-C type parameters, which allows us to express that (for example) an NSArray is covariant in its type parameter. This means that NSArray<NSMutableString *> * is a subtype of NSArray<NSString *> *, which is expected of the immutable Foundation collections. Type parameters can be annotated with __covariant or __contravariant to make them co- or contra-variant, respectively. This feature can be detected by __has_feature(objc_generics_variance). Implements rdar://problem/20217490. llvm-svn: 241549
* Implement the Objective-C __kindof type qualifier.Douglas Gregor2015-07-071-0/+1
| | | | | | | | | | The __kindof type qualifier can be applied to Objective-C object (pointer) types to indicate id-like behavior, which includes implicit "downcasting" of __kindof types to subclasses and id-like message-send behavior. __kindof types provide better type bounds for substitutions into unspecified generic types, which preserves more type information. llvm-svn: 241548
* C++ support for Objective-C lightweight generics.Douglas Gregor2015-07-071-0/+1
| | | | | | | | | | | | | | | | | | | Teach C++'s tentative parsing to handle specializations of Objective-C class types (e.g., NSArray<NSString *>) as well as Objective-C protocol qualifiers (id<NSCopying>) by extending type-annotation tokens to handle this case. As part of this, remove Objective-C protocol qualifiers from the declaration specifiers, which never really made sense: instead, provide Sema entry points to make them part of the type annotation token. Among other things, this properly diagnoses bogus types such as "<NSCopying> id" which should have been written as "id <NSCopying>". Implements template instantiation support for, e.g., NSArray<T>* in C++. Note that parameterized classes are not templates in the C++ sense, so that cannot (for example) be used as a template argument for a template template parameter. Part of rdar://problem/6294649. llvm-svn: 241545
* Make __has_feature(nullability) and __has_extension(nullability) always true.Douglas Gregor2015-06-291-4/+2
| | | | | | | These are _Underbar_capital-prefixed additions to the language that shouldn't depend on language standard. llvm-svn: 240976
* Make __has_extension(assume_nonnull) always true.Douglas Gregor2015-06-291-0/+1
| | | | llvm-svn: 240969
* [ObjC] Add NSValue support for objc_boxed_expressionsAlex Denisov2015-06-261-0/+1
| | | | | | | | | | | | | Patch extends ObjCBoxedExpr to accept records (structs and unions): typedef struct __attribute__((objc_boxable)) _Color { int r, g, b; } Color; Color color; NSValue *boxedColor = @(color); // [NSValue valueWithBytes:&color objCType:@encode(Color)]; llvm-svn: 240761
* Allow the cf_returns_[not_]retained attributes to appear on out-parameters.Douglas Gregor2015-06-191-0/+1
| | | | | | | | | | | | | | | | Includes a simple static analyzer check and not much else, but we'll also be able to take advantage of this in Swift. This feature can be tested for using __has_feature(cf_returns_on_parameters). This commit also contains two fixes: - Look through non-typedef sugar when deciding whether something is a CF type. - When (cf|ns)_returns(_not)?_retained is applied to invalid properties, refer to "property" instead of "method" in the error message. rdar://problem/18742441 llvm-svn: 240185
* Introduced pragmas for audited nullability regions.Douglas Gregor2015-06-191-0/+1
| | | | | | | | | | | | | | | | | Introduce the clang pragmas "assume_nonnull begin" and "assume_nonnull end" in which we make default assumptions about the nullability of many unannotated pointers: - Single-level pointers are inferred to __nonnull - NSError** in a (function or method) parameter list is inferred to NSError * __nullable * __nullable. - CFErrorRef * in a (function or method) parameter list is inferred to CFErrorRef __nullable * __nullable. - Other multi-level pointers are never inferred to anything. Implements rdar://problem/19191042. llvm-svn: 240156
* Introduce type nullability specifiers for C/C++.Douglas Gregor2015-06-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
* [ASan] Initial support for Kernel AddressSanitizerAlexander Potapenko2015-06-191-1/+3
| | | | | | | | | This patch adds initial support for the -fsanitize=kernel-address flag to Clang. Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported. Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux. To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used. llvm-svn: 240131
* [clang] Refactoring of conditions so they use isOneOf() instead of multiple ↵Daniel Marjamaki2015-06-181-4/+4
| | | | | | is(). llvm-svn: 240008
* Protection against stack-based memory corruption errors using SafeStack: ↵Peter Collingbourne2015-06-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Clang command line option and function attribute This patch adds the -fsanitize=safe-stack command line argument for clang, which enables the Safe Stack protection (see http://reviews.llvm.org/D6094 for the detailed description of the Safe Stack). This patch is our implementation of the safe stack on top of Clang. The patches make the following changes: - Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang to control safe stack usage (the safe stack is disabled by default). - Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be used to disable the safe stack for individual functions even when enabled globally. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6095 llvm-svn: 239762
* Refactor MacroInfo so macro arguments can be iterated with range-based for ↵Daniel Marjamaki2015-05-291-5/+1
| | | | | | | | | | loops. No functional change intended. Patch by Sebastian Edman! llvm-svn: 238547
* [modules] If we re-enter a submodule from within itself (when submoduleRichard Smith2015-05-211-10/+14
| | | | | | | | | | visibility is enabled) or leave and re-enter it, restore the macro and module visibility state from last time we were in that submodule. This allows mutually-#including header files to stand a chance at being modularized with local visibility enabled. llvm-svn: 237871
* [modules] Add local submodule visibility support for declarations.Richard Smith2015-05-151-1/+1
| | | | | | | | | | | | With this change, enabling -fmodules-local-submodule-visibility results in name visibility rules being applied to submodules of the current module in addition to imported modules (that is, names no longer "leak" between submodules of the same top-level module). This also makes it much safer to textually include a non-modular library into a module: each submodule that textually includes that library will get its own "copy" of that library, and so the library becomes visible no matter which including submodule you import. llvm-svn: 237473
* Have '__have_extension(cxx_variadic_templates)' return true for any C++ ↵Eric Fiselier2015-05-121-0/+1
| | | | | | standard. llvm-svn: 237202
* Disable __has_cpp_attribute when not compiling in C++ mode. As this feature ↵Aaron Ballman2015-05-111-1/+5
| | | | | | | | test macro only supports C++ style attributes, it doesn't apply to code compiled as C code, and can lead to diagnostics when given a scoped attribute. This addresses PR23435. llvm-svn: 236996
* Switch PPCallbacks to take the new MacroDefinition instead of ↵Richard Smith2015-05-041-9/+5
| | | | | | MacroDirective*, in order to preserve full information on module macro expansion. llvm-svn: 236404
* [modules] Start moving the module visibility information off the Module itself.Richard Smith2015-05-011-4/+4
| | | | | | | It has no place there; it's not a property of the Module, and it makes restoring the visibility set when we leave a submodule more difficult. llvm-svn: 236300
* Make macro dumping robust against a nonexistent macro.Richard Smith2015-04-301-1/+1
| | | | llvm-svn: 236285
* [modules] Add a mechanism to dump information about a macro.Richard Smith2015-04-301-0/+64
| | | | | | Wire this up to "#pragma clang __debug macro <name>". llvm-svn: 236280
* Remove dead code: a MacroDirective can't be imported or ambiguous any more.Richard Smith2015-04-301-1/+1
| | | | llvm-svn: 236197
* Fix unused variable warning.Richard Smith2015-04-291-1/+1
| | | | llvm-svn: 236178
* [modules] Stop trying to fake up a linear MacroDirective history.Richard Smith2015-04-291-40/+47
| | | | | | | | | | | | | | Modules builds fundamentally have a non-linear macro history. In the interest of better source fidelity, represent the macro definition information faithfully: we have a linear macro directive history within each module, and at any point we have a unique "latest" local macro directive and a collection of visible imported directives. This also removes the attendent complexity of attempting to create a correct MacroDirective history (which we got wrong in the general case). No functionality change intended. llvm-svn: 236176
* [modules] Incrementally compute the list of overridden module macros based onRichard Smith2015-04-271-37/+66
| | | | | | | the active module macros at the point of definition, rather than reconstructing it from the macro history. No functionality change intended. llvm-svn: 235941
* [modules] Properly attribute macros to modules if they're in a file ↵Richard Smith2015-04-231-2/+2
| | | | | | textually included into a file in the module. llvm-svn: 235661
* [modules] Store a ModuleMacro* on an imported macro directive rather than ↵Richard Smith2015-04-231-11/+8
| | | | | | duplicating the info within it. llvm-svn: 235644
* [modules] Determine the set of macros exported by a submodule at the end of ↵Richard Smith2015-04-231-17/+56
| | | | | | | | | | | that submodule. Previously we'd defer this determination until writing the AST, which doesn't allow us to use this information when building other submodules of the same module. This change also allows us to use a uniform mechanism for writing module macro records, independent of whether they are local or imported. llvm-svn: 235614
* [modules] Cope with partial module macro information, fix memory leak found ↵Richard Smith2015-04-221-0/+9
| | | | | | by buildbot. llvm-svn: 235464
* [modules] Build a DAG of module macros for each identifier.Richard Smith2015-04-221-0/+40
| | | | | | | | This graph will be used to determine the current set of active macros. This is foundation work for getting macro visibility correct across submodules of the current module. No functionality change for now. llvm-svn: 235461
* [lex] Provide a valid token when __has_include is found outside of a pp ↵Benjamin Kramer2015-03-291-0/+3
| | | | | | | | | | | directive ExpandBuiltinMacro would strip the identifier and downstream users crash when they encounter an identifier token with nullptr identifier info. Found by afl-fuzz. llvm-svn: 233497
* [lex] Don't create a garbage token if parsing of __has_include fails.Benjamin Kramer2015-03-291-2/+4
| | | | | | It will crash downstream somewhere. Found by afl-fuzz. llvm-svn: 233493
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-1/+1
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* Lex: Don't call getIdentifierInfo on annotation tokensDavid Majnemer2015-03-181-1/+1
| | | | | | | | These calls are usually guarded by checks for isAnnotation() but it looks like we missed a spot. This would cause the included test to crash clang. llvm-svn: 232616
* Teach raw_ostream to accept SmallString.Yaron Keren2015-03-101-1/+1
| | | | | | | | | | | | | | Saves adding .str() call to any raw_ostream << SmallString usage and a small step towards making .str() consistent in the ADTs by removing one of the SmallString::str() use cases, discussion at http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141013/240026.html I'll update the Phabricator patch http://reviews.llvm.org/D6372 for review of the Twine SmallString support, it's more complex than this one. llvm-svn: 231763
* Add clang support for Objective-C application extensions.Bob Wilson2015-03-021-0/+1
| | | | | | | | This adds the -fapplication-extension option, along with the ios_app_extension and macosx_app_extension availability attributes. Patch by Ted Kremenek llvm-svn: 230989
* Spelling correction.Yaron Keren2015-02-191-1/+1
| | | | llvm-svn: 229839
* Allow objc_bridge(id) to be used on typedefs of [cv] void*.John McCall2015-02-011-1/+2
| | | | | | rdar://19678874 llvm-svn: 227774
* Preprocessor: Recover instead of mutating a token in ExpandBuiltinMacroDavid Majnemer2014-12-151-4/+10
| | | | | | | | | | | We would CreateString on arbitrary garbage instead of just skipping to the end of the builtin macro. Eventually, this would cause us to crash because we would end up replacing the contents of a character token with a numeric literal. This fixes PR21825. llvm-svn: 224238
* [Objective-C]. This patch extends objc_bridge attribute to support ↵Fariborz Jahanian2014-12-111-0/+1
| | | | | | | | | | objc_bridge(id). This means that a pointer to the struct type to which the attribute appertains is a CF type (and therefore an Objective-C object of some type), but not of any specific class. rdar://19157264 llvm-svn: 224072
* Modify __has_attribute so that it only looks for GNU-style attributes. ↵Aaron Ballman2014-12-051-1/+1
| | | | | | Removes the ability to look for generic attributes and keywords via this macro, which has the potential to be a breaking change. However, since there is __has_cpp_attribute and __has_declspec_attribute, and given the limited usefulness of querying a generic attribute name regardless of syntax, this seems like the correct path forward. llvm-svn: 223468
* Added a new preprocessor macro: __has_declspec_attribute. This can be used ↵Aaron Ballman2014-12-051-0/+5
| | | | | | as a way to determine whether Clang supports a __declspec spelling for a given attribute, similar to __has_attribute and __has_cpp_attribute. llvm-svn: 223467
* Add support for has_feature(cxx_alignof) and has_feature(c_alignof).Nico Weber2014-12-031-0/+3
| | | | | | | r142020 added support for has_feature(cxx_alignas). This does the same for alignof. llvm-svn: 223186
* Silencing a -Wparentheses warning; NFC.Aaron Ballman2014-11-141-1/+1
| | | | llvm-svn: 221998
* Complete support for the SD-6 standing document (based off N4200) with ↵Aaron Ballman2014-11-141-5/+25
| | | | | | support for __has_cpp_attribute. llvm-svn: 221991
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-071-138/+139
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* [modules] Add support for #include_next.Richard Smith2014-10-201-5/+15
| | | | | | | | | | | | #include_next interacts poorly with modules: it depends on where in the list of include paths the current file was found. Files covered by module maps are not found in include search paths when building the module (and are not found in include search paths when @importing the module either), so this isn't really meaningful. Instead, we fake up the result that #include_next *should* have given: find the first path that would have resulted in the given file being picked, and search from there onwards. llvm-svn: 220177
OpenPOWER on IntegriCloud