| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
These are _Underbar_capital-prefixed additions to the language that
shouldn't depend on language standard.
llvm-svn: 240976
|
|
|
|
| |
llvm-svn: 240969
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
So, iterate over the list of macros mentioned in modules, and make sure those
are in the master table.
This isn't particularly efficient, but hopefully it's something that isn't
done too often.
PR23929 and rdar://problem/21480635
llvm-svn: 240571
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
| |
file in the loaded module maps and one of them is from the current module,
that's the right match.
llvm-svn: 240350
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
is().
llvm-svn: 240008
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
llvm-svn: 239789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
The RequestingModule argument was unused and always its default value of
nullptr.
Also move a declaration closer to its use, and range-for'ify.
llvm-svn: 239453
|
|
|
|
| |
llvm-svn: 239123
|
|
|
|
|
|
| |
Patch by Косов Евгений!
llvm-svn: 238774
|
|
|
|
|
|
|
|
|
|
| |
loops.
No functional change intended.
Patch by Sebastian Edman!
llvm-svn: 238547
|
|
|
|
|
|
|
|
|
|
|
|
| |
"1-4" specifiers are returned as numeric constants, not identifiers,
and should be treated as such. Currently pragma handler incorrectly
assumes that they are returned as identifiers.
Patch by Andrey Bokhanko.
Differential Revision: http://reviews.llvm.org/D9856
llvm-svn: 238129
|
|
|
|
| |
llvm-svn: 237872
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
glibc's headers use __need_* macros to selectively export parts of themselves
to each other. This requires us to enter those files repeatedly when building
a glibc module.
This can be unreverted once we have a better mechanism to deal with that
non-modular aspect of glibc (possibly some way to mark a header as "textual if
this macro is defined").
llvm-svn: 237718
|
|
|
|
|
|
|
|
|
|
| |
enter it more than once, even if it doesn't have #include guards -- we already
know that it is intended to have the same effect every time it's included, and
it's already had that effect. This particularly helps with local submodule
visibility builds, where the include guard macro may not be visible in the
includer, but will become visible the moment we enter the included file.
llvm-svn: 237609
|
|
|
|
|
|
|
| |
Fix a tiny bug where we'd try to load a module file for the module we're in
the middle of building.
llvm-svn: 237552
|
|
|
|
|
|
| |
modules is disabled, track submodule visibility anyway if -fmodules-local-submodule-visibility is enabled. This, in effect, gives modules semantics but without precompilation.
llvm-svn: 237550
|
|
|
|
|
|
| |
rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require.
llvm-svn: 237508
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
This, in preparation for the introduction of more new keywords in the
implementation of the C++ language, generalizes the support for future keyword
compat diagnostics (e.g., diag::warn_cxx11_keyword) by extending the
applicability of the relevant property in IdentifierTable with appropriate
renaming.
Patch by Hubert Tong!
llvm-svn: 237332
|
|
|
|
|
|
| |
change intended.
llvm-svn: 237331
|
|
|
|
|
|
| |
standard.
llvm-svn: 237202
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts commit 9242ff16b0460b488691fd70b42a2bf81a531e3a.
llvm-svn: 236806
|
|
|
|
| |
llvm-svn: 236804
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix PR22407, where the Lexer overflows the buffer when parsing
#include<\
(end of file after slash)
Test Plan:
Added a test that will trigger in asan build.
This case is also covered by the clang-fuzzer bot.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9489
llvm-svn: 236466
|
|
|
|
|
|
| |
MacroDirective*, in order to preserve full information on module macro expansion.
llvm-svn: 236404
|
|
|
|
|
|
|
|
|
|
| |
Preprocessor::MacroDefinition -> MacroDefinition.
clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.
llvm-svn: 236400
|
|
|
|
| |
llvm-svn: 236390
|
|
|
|
| |
llvm-svn: 236376
|
|
|
|
|
|
| |
overrides nothing.
llvm-svn: 236374
|
|
|
|
|
|
|
|
| |
should not export the macro.
... at least, not unless we have local submodule visibility enabled.
llvm-svn: 236369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.
So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.
llvm-svn: 236350
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 236285
|
|
|
|
|
|
| |
Wire this up to "#pragma clang __debug macro <name>".
llvm-svn: 236280
|
|
|
|
| |
llvm-svn: 236197
|
|
|
|
| |
llvm-svn: 236181
|
|
|
|
| |
llvm-svn: 236178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 236032
|
|
|
|
| |
llvm-svn: 235957
|