- Jun 20, 2015
-
-
Richard Smith authored
[modules] When determining whether a definition of a class is visible, check all modules even if we've already found a definition that's not visible. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240204 91177308-0d34-0410-b5e6-96231b3b80d8
-
Richard Smith authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240200 91177308-0d34-0410-b5e6-96231b3b80d8
-
Nico Weber authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240199 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240196 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240190 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
These usually apply to the return type. At one point this was necessary to get some of them to apply to the entire block, but it appears that's working anyway (see block-return.c). rdar://problem/20468034 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240189 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
...instead of as a special case in ParseObjCTypeName with lots of duplicated logic. Besides being a nice refactoring, this also allows "- (instancetype __nonnull)self" in addition to "- (nonnull instancetype)self". rdar://problem/19924646 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240188 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
rdar://problem/21134250 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240187 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
That is, void cf2(CFTypeRef * __nullable p CF_RETURNS_NOT_RETAINED); is equivalent to void cf2(CFTypeRef __nullable * __nullable p CF_RETURNS_NOT_RETAINED); More rdar://problem/18742441 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240186 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240185 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Jun 19, 2015
-
-
Alexey Samsonov authored
Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support and are not toolchain- or architecture-dependent. Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539). Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. This change was first submitted as r239953 and reverted in r239958. The problem was and still is in Darwin toolchains, which get the knowledge about target platform too late after initializaition, while now we require this information when ToolChain::getSanitizerArgs() is called. r240170 works around this issue. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240179 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240171 91177308-0d34-0410-b5e6-96231b3b80d8
-
Alexey Samsonov authored
Summary: This is unfortunate, but would let us land http://reviews.llvm.org/D10467, that makes ToolChains responsible for computing the set of sanitizers they support. Unfortunately, Darwin ToolChains doesn't know about actual OS they target until ToolChain::TranslateArgs() is called. In particular, it means we won't be able to construct SanitizerArgs for these ToolChains before that. This change removes SanitizerArgs::needsLTO() method, so that now ToolChain::IsUsingLTO(), which is called very early, doesn't need SanitizerArgs to implement this method. Docs and test cases are updated accordingly. See https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we start all these. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10560 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240170 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
Another part of rdar://problem/18868820. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240159 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
Adds a new warning (under -Wnullability-completeness) that complains about pointer, block pointer, or member pointer declarations that have not been annotated with nullability information (directly or inferred) within a header that contains some nullability annotations. This is intended to be used to help maintain the completeness of nullability information within a header that has already been audited. Note that, for performance reasons, this warning will underrepresent the number of non-annotated pointers in the case where more than one pointer is seen before the first nullability type specifier, because we're only tracking one piece of information per header. Part of rdar://problem/18868820. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240158 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240156 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
'null_resettable' properties are those whose getters return nonnull but whose setters take nil, to "reset" the property to some default. Implements rdar://problem/19051334. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240155 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
Introduce context-sensitive, non-underscored nullability specifiers (nonnull, nullable, null_unspecified) for Objective-C method return types, method parameter types, and properties. Introduce Objective-C-specific semantics, including computation of the nullability of the result of a message send, merging of nullability information from the @interface of a class into its @implementation, etc . This is the Objective-C part of rdar://problem/18868820. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240154 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240153 91177308-0d34-0410-b5e6-96231b3b80d8
-
Eric Christopher authored
intrinsic _mm_prefetch into a builtin rather than by textual inclusion via the intrinsic headers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240152 91177308-0d34-0410-b5e6-96231b3b80d8
-
Matt Arsenault authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240150 91177308-0d34-0410-b5e6-96231b3b80d8
-
Matt Arsenault authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240148 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Gregor authored
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240146 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Katzman authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240135 91177308-0d34-0410-b5e6-96231b3b80d8
-
Douglas Katzman authored
This change passes through C and assembler jobs to Movidius tools by constructing commands which are the same as ones produces by the examples in the SDK. But rather than reference MV_TOOLS_DIR to find tools, we will assume that binaries are installed wherever the Driver would find its native tools. Similarly, this change assumes that -I options will "just work" based on where SDK headers get installed, rather than baking into the Driver some magic paths. Differential Revision: http://reviews.llvm.org/D10440 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240134 91177308-0d34-0410-b5e6-96231b3b80d8
-
Alexander Potapenko authored
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240131 91177308-0d34-0410-b5e6-96231b3b80d8
-
Daniel Jasper authored
conservative. In particular, this fixes an unwanted corner case. Before: string s = someFunction("aaaa" "bbbb"); After: string s = someFunction( "aaaa" "bbbb"); git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240129 91177308-0d34-0410-b5e6-96231b3b80d8
-
Daniel Jasper authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240128 91177308-0d34-0410-b5e6-96231b3b80d8
-
Daniel Jasper authored
The previous one (r240021) regressed: enum E Type::f() { .. } git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240127 91177308-0d34-0410-b5e6-96231b3b80d8
-
Alexey Bataev authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240126 91177308-0d34-0410-b5e6-96231b3b80d8
-
Alexey Bataev authored
Base type of attribute((mode)) can actually be a vector type. The patch is to distinguish between base type and base element type. This fixes http://llvm.org/PR17453. Differential Revision: http://reviews.llvm.org/D10058 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240125 91177308-0d34-0410-b5e6-96231b3b80d8
-
Peter Collingbourne authored
Clang's control flow integrity implementation works by conceptually attaching "tags" (in the form of bitset entries) to each virtual table, identifying the names of the classes that the virtual table is compatible with. Under the Itanium ABI, it is simple to assign tags to virtual tables; they are simply the address points, which are available via VTableLayout. Because any overridden methods receive an entry in the derived class's virtual table, a check for an overridden method call can always be done by checking the tag of whichever derived class overrode the method call. The Microsoft ABI is a little different, as it does not directly use address points, and overrides in a derived class do not cause new virtual table entries to be added to the derived class; instead, the slot in the base class is reused, and the compiler needs to adjust the this pointer at the call site to (generally) the base class that initially defined the method. After the this pointer has been adjusted, we cannot check for the derived class's tag, as the virtual table may not be compatible with the derived class. So we need to determine which base class we have been adjusted to. Specifically, at each call site, we use ASTRecordLayout to identify the most derived class whose virtual table is laid out at the "this" pointer offset we are using to make the call, and check the virtual table for that tag. Because address point information is unavailable, we "reconstruct" it as follows: any virtual tables we create for a non-derived class receive a tag for that class, and virtual tables for a base class inside a derived class receive a tag for the base class, together with tags for any derived classes which are laid out at the same position as the derived class (and therefore have compatible virtual tables). Differential Revision: http://reviews.llvm.org/D10520 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240117 91177308-0d34-0410-b5e6-96231b3b80d8
-
Peter Collingbourne authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240115 91177308-0d34-0410-b5e6-96231b3b80d8
-
Eric Christopher authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240110 91177308-0d34-0410-b5e6-96231b3b80d8
-
Peter Collingbourne authored
This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240109 91177308-0d34-0410-b5e6-96231b3b80d8
-
Peter Collingbourne authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240106 91177308-0d34-0410-b5e6-96231b3b80d8
-
Peter Collingbourne authored
This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240105 91177308-0d34-0410-b5e6-96231b3b80d8
-
Richard Smith authored
imported definition. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240068 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Jun 18, 2015
-
-
Alexey Samsonov authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240065 91177308-0d34-0410-b5e6-96231b3b80d8
-
Tom Stellard authored
This fixes buildbot failures introduced by r240038. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240059 91177308-0d34-0410-b5e6-96231b3b80d8
-