summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/PPMacroExpansion.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Avoid a crash after loading an #undef'd macro in code completionBen Langmuir2014-09-301-1/+4
| | | | | | | | | | | In code-completion, don't assume there is a MacroInfo for everything, since we aren't serializing the def corresponding to a later #undef in the same module. Also setup the HadMacro bit correctly for undefs to avoid an assertion failure. rdar://18416901 llvm-svn: 218694
* C++1y is now C++14!Aaron Ballman2014-08-191-9/+9
| | | | | | 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. llvm-svn: 215982
* Use -Rblah, not -Wblah, to control remark diagnostics. This was always theRichard Smith2014-08-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | intent when we added remark support, but was never implemented in the general case, because the first -R flags didn't need it. (-Rpass= had special handling to accomodate its argument.) -Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark, or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything does not affect remarks, and -Reverything does not affect warnings or errors. The only "real" -R flag we have right now is -Rmodule-build; that flag is effectively renamed from -Wmodule-build to -Rmodule-build by this change. -Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and -Rno-pass by this change; it's not completely clear whether we intended to have a -Rpass (with no =pattern), but that is unchanged by this commit, other than the flag name. The default pattern is effectively one which matches no passes. In future, we may want to make the default pattern be .*, so that -Reverything works for -Rpass properly. llvm-svn: 215046
* DiagnosticIDs: use diagnostic severities to simplify extension handlingAlp Toker2014-06-221-2/+2
| | | | llvm-svn: 211479
* Implement -Wdate-time preprocessor warningAlp Toker2014-06-101-1/+4
| | | | | | | This GCC warning is useful for validating reproducible builds and might help when tracking down issues with modules too. llvm-svn: 210511
* Remove limits on the number of fix-it hints and ranges in the DiagnosticsEngine.Alexander Kornienko2014-05-221-16/+5
| | | | | | | | | | | | | | | | | | | Summary: The limits on the number of fix-it hints and ranges attached to a diagnostic are arbitrary and don't apply universally to all users of the DiagnosticsEngine. The way the limits are enforced may lead to diagnostics generating invalid sets of fixes. I suggest removing the limits, which will also simplify the implementation. Reviewers: rsmith Reviewed By: rsmith Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D3879 llvm-svn: 209468
* [C++11] Use 'nullptr'. Lex edition.Craig Topper2014-05-171-27/+29
| | | | llvm-svn: 209083
* PR19698, PR19674: enable __has_feature checks for cxx_generic_lambdas andRichard Smith2014-05-091-3/+8
| | | | | | | cxx_decltype_auto, and fix documentation of cxx_generic_lambdas and cxx_init_captures to specify the right feature-check name. llvm-svn: 208445
* Lex: Fix __has_feature(cxx_exceptions) for objective C++Justin Bogner2014-04-161-1/+1
| | | | | | | | | | | | | | | At one point, -fexceptions was a synonym for -fcxx-exceptions. While the driver options still enables cxx-exceptions by default, the cc1 flag is purely about exception tables and this doesn't account for objective C exceptions. Because of this, checking for the cxx_exceptions feature in objective C++ often gives the wrong answer. The cxx_exceptions feature should be based on the -fcxx-exceptions cc1 flag, not -fexceptions. Furthermore, at some point the tests were changed to use cc1 even though they were testing the driver behaviour. We're better off testing both the driver and cc1 here. llvm-svn: 206352
* Add a test to distinguish between reserved tokens and normal identifiers.Yunzhong Gao2014-04-111-0/+4
| | | | | | | | | | | | The -fms-extensions option affects a number of subtle front-end C/C++ behaviors, and it would be useful to be able to distinguish MS keywords from regular identifiers in the ms-extensions mode even if the triple does not define a Windows target. It should make life easier if anyone needs to port their Windows codes to elsewhere. Differential Revision: http://reviews.llvm.org/D3034 llvm-svn: 206069
OpenPOWER on IntegriCloud