Appease MSVC 2013 a few more times, which was complaining about a syntax error with an unexpected close curly brace. For some reason, the range-based for loop requires curly braces to compile in MSVC.
Appease MSVC 2013, which was complaining about a syntax error with an unexpected close curly brace. For some reason, the range-based for loop requires curly braces to compile in MSVC.
Douglas Gregor [Tue, 7 Jul 2015 06:20:12 +0000 (06:20 +0000)]
The AST importer had a bug where it would enter into an infinite recursion
when importing type parameter lists. The reason is that type parameters
have their DeclContexts set to the interface that is parameterized with those
types, and the importer would follow that loop and blow the stack out.
I've changed the way this works so that the type parameters are only imported
after the interface that contains them has been registered via the Imported()
function.
Douglas Gregor [Tue, 7 Jul 2015 03:58:54 +0000 (03:58 +0000)]
Implement variance for Objective-C type parameters.
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.
Douglas Gregor [Tue, 7 Jul 2015 03:58:42 +0000 (03:58 +0000)]
Implement the Objective-C __kindof type qualifier.
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.
Douglas Gregor [Tue, 7 Jul 2015 03:58:28 +0000 (03:58 +0000)]
Warn when an intended Objective-C specialization was actually a useless protocol qualification.
Warn in cases where one has provided redundant protocol qualification
that might be a typo for a specialization, e.g., NSArray<NSObject>,
which is pointless (NSArray declares that it conforms to NSObject) and
is likely to be a typo for NSArray<NSObject *>, i.e., an array of
NSObject pointers. This warning is very narrow, only applying when the
base type being qualified is parameterized, has the same number of
parameters as their are protocols listed, all of the names can also
refer to types (including Objective-C class types, of course), and at
least one of those types is an Objective-C class (making this a typo
for a missing '*'). The limitations are partly for performance reasons
(we don't want to do redundant name lookup unless we really need to),
and because we want the warning to apply in very limited cases to
limit false positives.
Douglas Gregor [Tue, 7 Jul 2015 03:58:22 +0000 (03:58 +0000)]
Warn when an Objective-C collection literal element is converted to an incompatible type.
Objective-C collection literals produce unspecialized
NSArray/NSDictionary objects that can then be implicitly converted to
specialized versions of these types. In such cases, check that the
elements in the collection are suitable for the specialized
collection. Part of rdar://problem/6294649.
Douglas Gregor [Tue, 7 Jul 2015 03:58:14 +0000 (03:58 +0000)]
C++ support for Objective-C lightweight generics.
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.
Douglas Gregor [Tue, 7 Jul 2015 03:58:01 +0000 (03:58 +0000)]
Improve the Objective-C common-type computation used by the ternary operator.
The Objective-C common-type computation had a few problems that
required a significant rework, including:
- Quadradic behavior when finding the common base type; now it's
linear.
- Keeping around type arguments when computing the common type
between a specialized and an unspecialized type
- Introducing redundant protocol qualifiers.
Part of rdar://problem/6294649. Also fixes rdar://problem/19572837 by
addressing a longstanding bug in
ASTContext::CollectInheritedProtocols().
Douglas Gregor [Tue, 7 Jul 2015 03:57:53 +0000 (03:57 +0000)]
Substitute type arguments into uses of Objective-C interface members.
When messaging a method that was defined in an Objective-C class (or
category or extension thereof) that has type parameters, substitute
the type arguments for those type parameters. Similarly, substitute
into property accesses, instance variables, and other references.
This includes general infrastructure for substituting the type
arguments associated with an ObjCObject(Pointer)Type into a type
referenced within a particular context, handling all of the
substitutions required to deal with (e.g.) inheritance involving
parameterized classes. In cases where no type arguments are available
(e.g., because we're messaging via some unspecialized type, id, etc.),
we substitute in the type bounds for the type parameters instead.
When substituting for the type parameters given an unspecialized
context (i.e., no specific type arguments were given), substituting
the type bounds unconditionally produces type signatures that are too
strong compared to the pre-generics signatures. Instead, use the
following rule:
- In covariant positions, such as method return types, replace type
parameters with “id” or “Class” (the latter only when the type
parameter bound is “Class” or qualified class, e.g,
“Class<NSCopying>”)
- In other positions (e.g., parameter types), replace type
parameters with their type bounds.
- When a specialized Objective-C object or object pointer type
contains a type parameter in its type arguments (e.g.,
NSArray<T>*, but not NSArray<NSString *> *), replace the entire
object/object pointer type with its unspecialized version (e.g.,
NSArray *).
Douglas Gregor [Tue, 7 Jul 2015 03:57:35 +0000 (03:57 +0000)]
Handle Objective-C type arguments.
Objective-C type arguments can be provided in angle brackets following
an Objective-C interface type. Syntactically, this is the same
position as one would provide protocol qualifiers (e.g.,
id<NSCopying>), so parse both together and let Sema sort out the
ambiguous cases. This applies both when parsing types and when parsing
the superclass of an Objective-C class, which can now be a specialized
type (e.g., NSMutableArray<T> inherits from NSArray<T>).
Check Objective-C type arguments against the type parameters of the
corresponding class. Verify the length of the type argument list and
that each type argument satisfies the corresponding bound.
Specializations of parameterized Objective-C classes are represented
in the type system as distinct types. Both specialized types (e.g.,
NSArray<NSString *> *) and unspecialized types (NSArray *) are
represented, separately.
Douglas Gregor [Tue, 7 Jul 2015 03:57:15 +0000 (03:57 +0000)]
Parsing, semantic analysis, and AST for Objective-C type parameters.
Produce type parameter declarations for Objective-C type parameters,
and attach lists of type parameters to Objective-C classes,
categories, forward declarations, and extensions as
appropriate. Perform semantic analysis of type bounds for type
parameters, both in isolation and across classes/categories/extensions
to ensure consistency.
Also handle (de-)serialization of Objective-C type parameter lists,
along with sundry other things one must do to add a new declaration to
Clang.
Note that Objective-C type parameters are typedef name declarations,
like typedefs and C++11 type aliases, in support of type erasure.
Adrian Prantl [Tue, 7 Jul 2015 00:49:35 +0000 (00:49 +0000)]
Debug info: Emit distinct __block_literal_generic types for blocks with
different function signatures. (Previously clang would emit all block
pointer types with the type of the first block pointer in the compile
unit.)
This reverts commit r241244, but restricts SEH support to Win64.
This way, Chromium builds will still fall back on TUs with SEH, and
Clang developers can work on this incrementally upstream while patching
this small predicate locally. It'll also make it easier to review small
fixes.
Davide Italiano [Mon, 6 Jul 2015 18:02:09 +0000 (18:02 +0000)]
[Sema] Warn when shifting a negative value.
Example:
% ./clang -Wshift-negative-value emit.c
emit.c:3:14: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
int a = -1 << 3;
~~ ^
1 warning generated.
Teresa Johnson [Mon, 6 Jul 2015 16:23:00 +0000 (16:23 +0000)]
Resubmit "Pass down the -flto option to the -cc1 job" (r239481)
The patch is the same except for the addition of a new test for the
issue that required reverting the dependent llvm commit.
--Original Commit Message--
Pass down the -flto option to the -cc1 job, and from there into the
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
Daniel Jasper [Mon, 6 Jul 2015 11:30:34 +0000 (11:30 +0000)]
clang-format: Fix __attribute__ being treated as decl name.
__attribute__ was treated as the name of a function definition, with the
tokens in parentheses being the parameter list. This formats incorrectly
with AlwaysBreakAfterDefinitionReturnType. Fix it by treating
__attribute__ like decltype.
Richard Smith [Mon, 6 Jul 2015 04:43:58 +0000 (04:43 +0000)]
PR24030, PR24033: Consistently check whether a new declaration conflicts with
an existing using shadow declaration if they define entities of the same kind
in different namespaces.
We'd previously check this consistently if the using-declaration came after the
other declaration, but not if it came before.
[CMake] clang-*.*: Prevent versioning if the buildhost is targeting for Win32.
CMake-2.8.12 is hardcoded to create symlinked clang.exe if the target property VERSION is present and the host is not Win32.
Then clang.exe-*.* is generated and clang.exe is symlinked to it.
- Refactored ARMTargetInfo in order to use the API of llvm/lib/Support/TargetParser.cpp
for extracting target specific information.
- Patch for commit 241267: ShouldUseInlineAtomic was set incorrectly when subArch was
not specified, causing regressions.
Driver: Replace a couple of out of date terms in the docs
The Job base class was removed in r241310, so replace a couple of
references to it with Command. Also change another use of Job with
Action, since that's the term used in the source.
We had a strange relationship here where we made a list of Jobs
inherit from a single Job, but there weren't actually any places where
this arbitrary nesting was used or needed.
Simplify all of this by removing Job entirely and updating all of the
users to either work with a JobList or a single Command.
When testing for anyOf(), the test should not be for an exact type match for all members of the set. Instead, test that all members are convertible to the common type.
Ben Langmuir [Thu, 2 Jul 2015 13:19:48 +0000 (13:19 +0000)]
[Modules] Be consistent about finding a module for framework headers
We use findModuleForHeader() in several places, but in header search we
were not calling it when a framework module didn't show up with the
expected name, which would then lead to unexpected non-modular includes.
Now we will find the module unconditionally for frameworks. For regular
frameworks, we use the spelling of the module name from the module map
file, and for inferred ones we use the canonical directory name.
In the future we might want to lock down framework modules sufficiently
that these name mismatches cannot happen.
projects / clang / log