We create new expressions that have the type on the expression
set. Make sure we capture these types in the constraint system type
map so that we can refer to types uniformally by consulting the map.
NFC.
First, ensure all ParamDecls that are synthesized from scratch are given
both a contextual type and an interface type.
For ParamDecls written in source, add a new recordParamType() method to
GenericTypeResolver. This calls setType() or setInterfaceType() as
appropriate.
Interestingly enough a handful of diagnostics in the test suite have
improved. I'm not sure why, but I'll take it.
The ParamDecl::createUnboundSelf() method is now only used in the parser,
and no longer sets the type of the self parameter to the unbound generic
type. This was wrong anyway, since the type was always being overwritten.
This allows us to remove DeclContext::getSelfTypeOfContext().
Also, ensure that FuncDecl::getBodyResultTypeLoc() always has an interface
type for synthesized declarations, eliminating a mapTypeOutOfContext()
call when computing the function interface type in configureInterfaceType().
Finally, clean up the logic for resolving the DynamicSelfType. We now
get the interface or contextual type of 'Self' via the resolver, instead
of always getting the contextual type and patching it up inside
configureInterfaceType().
After recent changes, this asserts on all decls that are not VarDecls,
so we can just enforce that statically now. Interestingly, this turns
up some dead code which would have asserted immediately if called.
Also, replace AnyFunctionRef::getType() with
AnyFunctionRef::getInterfaceType(), since the old
AnyFunctionRef::getType() would just assert when called on
a Decl.
When cast expressions (conditional or forced downcasts) are part
of the closure expression with invalid parameters or return type,
they are not going be to folded by PreCheckExpression, which means
that they are not going to have sub-expression (from) set.
Resolves: <rdar://problem/27464577>.
The ASTContext had a wacky "get member type" callback that actually
called back into the constraint system (!) to build member types. This
callback was obsoleted by the change that started representing nested
types as DependentMemberTypes.
It's possible some of the asserts will eventually migrate to something
like test-and-return, but at least for now let's ensure that we know
when this is happening.
This is not comprehensive. There are other places we are creating fresh
constraint systems and then creating constraints using type variables
from a pre-existing constraint systems.
[CodeCompletion] Using the default constraints generator for TupleExpr
when inferring the type of unresolved members. rdar://28991372
When code completing, we used to create a type variable to represent the type
of an entire tuple expression. However, recent improvements on parser make this
step unnecessary and crash-prone. Thus, we use the default constraint
generator to interpret tuple expressions.
When adding constraints into the constraint system, don't immediately
allocate a Constraint and add it via the most-general
addConstraint(). Instead, go through a more specific entrypoint (e.g.,
addValueMemberConstraint, addRestrictedConstraint, etc.), so we can
start phasing out the general "add an already-formed constraint"
function. NFC
The 'literalConformanceProto' field of
TypeVariableType::Implementation didn't take into account equivalence
classes of type variables. Eliminate it, and either look at the actual
expressions (for optimizing constraints during constraint generation)
or the actual constraints on a given type variable (for determining
whether to include optionals in the set of potential type variable
bindings).
(cherry picked from commit 6bdd9cfae5)
This reverts commit 6bdd9cfae5. This
commit *appears* to be breaking something in Dollar involving
inference with array literals and 'nil'; pull it back for more
investigation.
The 'literalConformanceProto' field of
TypeVariableType::Implementation didn't take into account equivalence
classes of type variables. Eliminate it, and either look at the actual
expressions (for optimizing constraints during constraint generation)
or the actual constraints on a given type variable (for determining
whether to include optionals in the set of potential type variable
bindings).
While, tracking defaulted constraints based on their type variable
usually works in practice, it can break if the type variable ends up
being equivalent to some other type variable that. Instead, record the
locators associated with Defaultable constraints where we used the
default, which are easier to work with during constraint application.
In most places where we were checking "is<ErrorType>()", we now mean
"any error occurred". The few exceptions are in associated type
inference, code completion, and expression diagnostics, where we might
still work with partial errors.
This particular flag should only be used in rare cases where we don't
want to know about failures, but instead want to get some
partially-formed type. Only very specific parts of the type checker
need this (associated type inference), and code completion relies on
it for slightly-better results.
When generating constraints for subscript convert InOutType into LValueType,
because base of the subscript should never be marked as inout, but rather as
@lvalue to denote mutability.
Resolves <rdar://problem/25601561>.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
The constraint generator's optimization to eagerly merge type
variables for different keys in a dictionary literal was too eager,
merging the type variables for (e.g.) a string literal and an integer
literal. This prevented us from properly inferring AnyHashable key
types in dictionary literals. Fixes the rest of rdar://problem/27661580.
The problem here is that we would just emit 'invalid pattern'
instead of digging deeper, which meant that the fix-it for
qualified enum element access wasn't getting inserted for
more complex patterns, such as 'case X(let x)'.
Unfortunately, in the matching_patterns.swift test, we emit
too many diagnostics that are not really useful to figuring
out the problem, and the old 'invalid pattern' made more
sense. I'll work on some CSDiag tweaks to address this --
I think it makes more sense to dig there than just emit a
general 'invalid pattern' diagnostic anyway.
Fixes <rdar://problem/27684266>.
The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
"California": [
"population": 37_000_000,
"cities": ["Los Angeles", "San Diego", "San Jose"],
],
"Oregon": [
"population": 4_000_000,
"cities": ["Portland", "Salem", "Eugene"],
]
]
Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.
Synthesizing a VarDecl for #dsohandle causes some unwanted accessors to
be expected, but we really don't need them: this is a global variable
for the start of the image. There are only two uses of getDSOHandle:
getting the type and emitting the SIL for it. Rather than perform
acrobatics to turn off switches, just emit access directly where it's
needed.
rdar://problem/26565092
I keep wanting to debug type-checking of unresolved members, so add the
logic so I can enable it from swift-ide-test rather than having to
modify the source.
Extend the handling of function reference kinds to member references
(e.g., x.f), and therefore the logic for stripping argument labels. We
appear to be stripping argument labels from all of the places where it
is required.
When referencing a function in the type checker, drop argument labels
when we don't need them to type-check an immediate call to that
function. This provides the semantic behavior of SE-0111, e.g.,
references to functions as values produce unlabeled function types,
without the representational change of actually dropping argument
labels from the type system.
At the moment, this only works for bare references to functions. It
still needs to be pushed through more of the type checker and more AST
nodes to work in the general case.
Keep this work behind the frontend flag
-suppress-argument-labels-in-types for now.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
This reverts commit dc24c2bd34.
Turns out Chris fixed the build but when I was looking at the bots, his fix had
not been tested yet, so I thought the tree was still red and was trying to
revert to green.
