A GenericEnvironment stores the mapping between GenericTypeParamTypes
and context archetypes (or eventually, concrete types, once we allow
extensions to constrain a generic parameter to a concrete type).
The goals here are two-fold:
- Eliminate the GenericTypeParamDecl::getArchetype() method, and
always use mapTypeIntoContext() instead
- Replace SILFunction::ContextGenericParams with a GenericEnvironment
This patch adds the new data type as well as serializer and AST
verifier support. but nothing else uses it yet.
Note that GenericSignature::get() now asserts if there are no
generic parameters, instead of returning null. This requires a
few tweaks here and there.
When synthesizing the witness for Error._code, synthesize it as
final. This isn't meant to be user-visible (and, therefore, isn't
meant to be user-overridable), so it's a minor efficiency
win. Moreover, we weren't making sure this member got synthesized in
in cross-module situations, leading to runtime crashes. Fixes
rdar://problem/27335637.
More detail: some members are intended to have the same the access as
their containing types. This doesn't fly for SE-0025 'private', which
would limit the members to only being accessed from lexically within
the type decl, instead anywhere the type itself can be seen. Instead,
follow the rule for user-written members---internal by default---and
then raise the access level to 'public' if necessary. This affects:
- enum cases
- deinitializers
- protocol requirements
- generic parameters
- implicit initializers
- inherited initializers
- derived conformance members
- synthesized typealiases for associated types
Previously getInterfaceType() would punt to getType() if no
interface type was set. This patch changes getInterfaceType()
to assert if no interface type is set, and updates various
places to set the interface type explicitly.
This brings us a step closer to removing PolymorphicFunctionType.
The code in recordTypeWitness() seemed to be completely bogus;
it already receives a type written in terms of the archetypes
of the adoptee's context, so mapTypeOutOfContext() did nothing
here, because it was using the wrong substitutions.
The logic for synthesizing designated initializers was also
slightly wrong if the class was nested inside a generic
function.
Finally, interface and contextual types of a derived rawValue
were flipped around.
I originally added this so that we would keep the signature around
even if type checking failed, and the function was given an
ErrorType.
Add a formal check to the AST verifier for this, and set the signature
in a few places where it wasn't being set.
Note that since we only serialize valid declarations, we don't have
to serialize a reference to the generic signature separately, but we
do have to remember to set it when deserializing, which wasn't being
done for destructors.
The fix for methods to lower the dynamic method type from the substituted AST type of the expression also needed to be applied to the optional chaining, subscript, and property paths.
This also exposed a problem in the Clang importer, where imported subscript accessors would get the unbound generic context type as their Self parameter type instead of the type with the correct generic parameters. Fix this by renaming the all-too-convenient ParamDecl::createSelf factory to `createUnboundSelf`, and introduce a new `createSelf` that uses the bound generic type.
Fixes rdar://problem/26447758.
The verifier now asserts that Throws, ThrowsLoc and isBodyThrowing()
match up.
Also, add /*Label=*/ comments where necessary to make the long argument
lists easier to read, and cleaned up some inconsistent naming conventions.
I caught a case where ClangImporter where we were passing in a loc as
StaticLoc instead of FuncLoc, but probably this didn't affect anything.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
This is the first in a series of patches that fixes some resilience-related
issues with synthesized accessors and materializeForSet.
Previously we maintained two lists of external declarations encountered while
type checking:
- ASTContext::ExternalDefinitions
- TypeChecker::implicitlyDefinedFunctions
The former contained the following:
- Imported nominal types from Clang, so that SILGen can emit witness tables
- Functions and variables with Clang decls, so that IRGen can instruct Clang
to emit them
- Synthesized accessors
The latter contained synthesized functions for derived conformances.
Since the second list was not visible outside Sema, we relied on the Clang
importer to add the type that contained the declaration to the
ExternalDefinitions list. In practice, we only synthesized members of enums
in this manner.
Because of this, SILGenModule::emitExternalDefinitions() had special logic to
skip members of enums, since it would visit them when visiting the enum itself.
Instead, it appears that we can remove implicitlyDefinedFunctions completely,
changing usage sites to add the decl to ExternalDefinitions instead, and
simplify SILGenModule::emitExternalDefinition() a bit in the process.
Also, it looks like we never had Modules appear in ExternalDefinitions, so
assert if those come up instead of skipping them.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
This is more complex than it could be if ExtensionDecl and NominalTypeDecl
had a common ancestor in the Decl hierarchy, however this is not possible
right now because TypeDecl inherits from ValueDecl.
Fixes <rdar://problem/20981254>.
Swift SVN r28941
This allows @objc enum error types produced in Objective-C (e.g., via
+[NSError errorWithDomain:code:userInfo:]) to be bridged back to their
original enum types in Swift via pattern matching/catch blocks.
This finishes rdar://problem/20577517.
Swift SVN r28803
On that testcase, we now generate:
t.swift:8:22: error: integer literal '123456' overflows when stored into 'UInt8'
case tooFarByFar = 123456
^
t.swift:7:8: error: integer literal '256' overflows when stored into 'UInt8'
case twoHundredFiftySix
^
instead of spitting out some warnings with no source loc (which Xcode eats).
This patch:
- Propagates source locations for literals when synthesizing code in various places,
so we get the right diagnostic at the right spot.
- Improves the constant folding SIL Pass to print the value overflowing, which is
necessary for cases with an implicit value (like 256 above), and is general goodness
for the QoI of the diagnostic anyway.
Swift SVN r27756
Inference of type witnesses for associated types was previously
implemented as part of value witness matching in the constraint
solver. This led to a number of serious problems, including:
- Recursion problems with the solver hunting for a type witness,
which triggers more attemts to match value witnesses...
- Arbitrarily crummy attempts to break the recursion causing
type-check failures in fun places.
- Ordering dependencies abound: different results depending on which
value witnesses were satisfied first, failures because of the order
in which we attempted to infer type witnesses, etc.
This new implementation of type witness inference uses a separate pass
that occurs whenever we're looking for any type witness, and solves
all of the type witnesses within a given conformance
simultaneously. We still look at potential value witnesses to infer
type witnesses, but we match them structurally, without invoking the
constraint solver.
There are a few caveats to this implementation:
* We're not currently able to infer type witnesses from value
witnesses that are global operators, so some tricks involving global
operators (*cough* ~> *cough*) might require some manually-specified
type witnesses. Note that the standard library doesn't include any
such cases.
* Yes, it's another kind of solver. At simple one, fortunately.
On the other hand, this implementation should be a big step forward:
* It's far more predictable, order-invariant, and non-recursive.
* The diagnostics for failures to infer type witnesses have
improved.
Fixes rdar://problem/20598513.
Swift SVN r27616
Introduce basic validation for throwing @objc initializers, e.g., a
failable @objc initializer cannot also be throwing. However,
Objective-C selector computation is broken.
Swift SVN r27292
Provide compiler-synthesized implementations of ErrorType that use the type name as domain and a per-case integer as code. (TBD would be some mapping of the associated data to userInfo in Cocoa.)
Swift SVN r26780
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
Fix a mismatch in the generated interface type and contextual type for the init(rawValue:) initializer; the former was lacking the '(rawValue:)' label and freaking out SILGen's abstraction lowering. When deriving the body of init(rawValue:), substitute the (interface) raw type into the initializer's context, so that we can successfully compare it to other contextualized types in the body's context. Fixes <rdar://problem/19986886>.
Swift SVN r25775
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
Provides consistency in behavior, particularly in enum raw values, where we reject non-literals. Factor out a common NumberLiteralExpr base for integer and float literals that handles the common sign and representation stuff. Fixes rdar://problem/16504472.
Swift SVN r23390
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
Per API review with Ali. While we're here, give the initializer a corresponding 'rawValue' argument label, and change the associated type name to RawValue to match.
Swift SVN r21888
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
No validation is done yet on whether the user-specified access control makes
sense in context, but all ValueDecls should at least /have/ accessibility now.
/Still/ no tests yet. They will be much easier to write once we're actually
enforcing access control and/or printing access control.
Swift SVN r19143
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
As part of this, use tail allocation to reduce the memory footprint of
TupleExprs. Use factory methods to make it easier to construct.
I'll be using this information in a follow-on patch. SourceKit
probably wants it as well.
Swift SVN r17129
