Commit Graph

7976 Commits

Author SHA1 Message Date
Doug Gregor
c9f501355d [Type checker] Allow the '==' on Ints to become a static method.
Various parts of the type checker (related to enum == synthesis) rely
on == for Ints being a module-scope function, which is silly. Remove
the restriction. Fixes rdar://problem/29029561.
2016-10-31 16:14:34 -07:00
swift-ci
754223d384 Merge pull request #5558 from DougGregor/witness-subst-cleanup 2016-10-31 14:35:36 -07:00
Doug Gregor
852cda6c75 [Conformance checking] Factor requirement environment into its own type.
Rather than computing the requirement environment as a tuple of
(generic signature, generic environment, substitution map),
encapsulate the result in a new RequirementEnvironment
class. Moreover, create a RequirementEnvironment once and re-use it
when matching each of the witnesses, because the environment itself
doesn't change---only the substitutions do. This saves us some work
when there are multiple potential witnesses (which is common).
2016-10-31 14:11:58 -07:00
Doug Gregor
0fe28ea798 Fix witness substitution computation for property behaviors.
My recent refactoring of witnesses in Sema and the AST disabled a
test for property behaviors, because they were no longer handling
substitutions correctly. Introduce a type checker entrypoint to record
information about a known witness, using the normal witness-matching
logic rather than trying to synthesize the correct answer (and getting
it wrong).

Note that I had to manually introduce some type witnesses to get the
property behavior tests passing, because the property-behavior code is
(intentionally) not introducing implicit typealiases for the type
witnesses it synthesized. The old witness-synthesizing code worked
around this issue, but the new code does not. A different fix is in
the works (i.e., better handling of type witnesses in the constraint
solver), so we'll take this temporary regression in an experimental
feature.
2016-10-31 13:50:48 -07:00
swift-ci
cbc9d895cd Merge pull request #5559 from rudkx/clean-up-handling-favored-constraint 2016-10-31 12:43:40 -07:00
Xi Ge
911f7b1805 [CodeCompletion] Using the default constraints generator for TupleExpr (#5557)
[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.
2016-10-31 12:00:50 -07:00
Mark Lacey
12cf13de8e Remove dead code related to tracking favored constraints.
At one point this was added in order to inhibit some bridging
conversions while we are handling favored constraints, but that code has
been removed now, making this dead.

Noticed by inspection.
2016-10-31 11:44:25 -07:00
swift-ci
3fc5aef425 Merge pull request #5545 from xedin/r28909024 2016-10-31 10:44:01 -07:00
Doug Gregor
c587c69f38 Merge pull request #5536 from ahoppen/SR-3043-deinit-reference
[TypeChecker] Add error message when accessing a type's destructor
2016-10-31 10:03:43 -07:00
Doug Gregor
a66b35d79b [Constraint solver] Allow constraint regeneration when inputs are simplified.
When we process a constraint, the first step is generally to call
getFixedTypeRecursive() to look through type variables. When this
operation actually does non-trivial work, we could save
that result by considering the current constraint "solved" and
generating a new constraint (if needed!) with the simplified types.

This commit adds the infrastructure to do that, because it's important
when getFixedTypeRecursive() starts performing more interesting
substitutions (e.g., handling member types of type
variables). However, enabling for the common case of looking through a
type variable isn't profitable (it's ~2% slower to type-check the
standard library). Stage in this infrastructure change now.
2016-10-31 09:27:22 -07:00
Doug Gregor
99daad0f30 Rework witness matching for generic requirements.
Reimplement the witness matching logic used for generic requirements
so that it properly models the expectations required of the witness,
then captures the results in the AST. The new approach has a number of
advantages over the existing hacks:

* The constraint solver no longer requires hacks to try to tangle
  together the innermost archetypes from the requirement with the
  outer archetypes of the context of the protocol
  conformance. Instead, we create a synthetic set of archetypes that
  describes the requirement as it should be matched against
  witnesses. This eliminates the infamous 'SelfTypeVar' hack.
* The type checker no longer records substitutions involving a weird
  mix of archetypes from different contexts (see above), so it's
  actually plausible to reason about the substitutions of a witness. A
  new `Witness` class contains the declaration, substitutions, and all
  other information required to interpret the witness.
* SILGen now uses the substitution information for witnesses when
  building witness thunks, rather than computing all of it from
  scratch. ``substSelfTypeIntoProtocolRequirementType()` is now gone
  (absorbed into the type checker, and improved from there), and the
  witness-thunk emission code is simpler. A few other bits of SILGen
  got simpler because the substitutions can now be trusted.
* Witness matching and thunk generation involving generic requirements
  and nested generics now works, based on some work @slavapestov was
  already doing in this area.
* The AST verifier can now verify the archetypes that occur in witness substitutions.
* Although it's not in this commit, the `Witness` structure is
  suitable for complete (de-)serialization, unlike the weird mix of
  archetypes previously present.

Fixes rdar://problem/24079818 and cleans up an area that's been messy
and poorly understood for a very, very long time.
2016-10-30 23:15:43 -07:00
Pavel Yaskevich
02cae22541 [Diagnostics] Extend contextual failure checking to all apply expressions
As an extension of SR-2208 apply contextual conversion failure checking
to all of the expressions diagnosed via FailureDiagnosis::visitApplyExpr.

Resolves <rdar://problem/28909024>.
2016-10-30 22:28:26 -07:00
Alex Hoppen
b0e67da844 [TypeChecker] Add error message when accessing a type's destructor
Provide error messages when the destructor is accessed using foo.deinit
instead of crashing

This resolves SR-2652 and SR-3043
2016-10-30 19:43:57 +00:00
practicalswift
59a2b28239 [gardening] Fix recently introduced typos. 2016-10-28 22:28:55 +02:00
swift-ci
9c4f1a5815 Merge pull request #5506 from DougGregor/fix-28145033 2016-10-27 22:17:04 -07:00
Doug Gregor
33ad7a8473 [Constraint solver] Remove erroneous constraints from the constraint graph.
When a constraint fails, we retire it... but we also need to remove it
from the constraint graph. Otherwise, we break invariants when
diagnostic generation attempts to continue simplification.

Fixes rdar://rdar28145033.
2016-10-27 21:35:14 -07:00
swift-ci
ee072910da Merge pull request #4541 from xwu/refactor-memory-layout-diagnostic 2016-10-26 22:48:40 -07:00
Pavel Yaskevich
dd01b7e184 [Diagnostics] SR-2208: Improve failure diagnostics for apply expressions 2016-10-26 14:34:05 -07:00
Doug Gregor
b295106830 [Constraint solver] Use the type representative in the "occurs" check.
When performing the occurs check, look for the *representative* of the
type variable we're about to bind, rather than the type variable
itself. Fixes rdar://problem/26845038, SR-1512, SR-1902, SR2635,
SR-2852, and SR-2766.
2016-10-25 22:37:21 -07:00
Doug Gregor
c58aafdce5 [Constraint solver] Unify the two typeVarOccursInType implementations.
NFC, thanks @CodaFi!
2016-10-25 14:13:31 -07:00
Doug Gregor
4cc41e5e64 [Constraint solver] Perform the "occurs" check properly.
We've been performing the "occurs" check when computing potential
bindings for type variables, but we weren't actually performing the
check for bindings that *must* occur. Perform the occurs check before
binding type variables, which fixes a few crashers and is far more principled.

Note that this obviates the need for tracking the type variables we've
substituted in simplifyType(), so simplify that as well.

Fixes rdar://problem/27879334 / SR-2351.
2016-10-25 13:32:06 -07:00
Doug Gregor
b484cbb6b9 [Constraint solver] Eliminate TypeMatchKind. NFC
It's no more than a subset of ConstraintKind with a bunch of
boilerplate to convert back and forth. Just use ConstraintKind.
2016-10-24 23:26:07 -07:00
Doug Gregor
a65812c558 [Constraint solver] Add ConstraintKind::BindToPointerType.
This matches up with TypeMatchKind::BindToPointerType.
2016-10-24 21:24:49 -07:00
Xiaodi Wu
185a73e542 Refactor diagnoseMemoryLayoutMigration [NFC] 2016-10-24 18:27:54 -05:00
Doug Gregor
d790291c48 [Constraint solver] Replace a use of simplifyType() with getFixedTypeRecursive()
The latter is cheaper to compute, and suitable for the
is-it-a-metatype check.
2016-10-24 13:19:58 -07:00
Doug Gregor
419fb80910 [Constraint solver] Only add defaultable types on the actual type variable.
When adding a defaultable type, make sure that the type being
defaulted is actually the type variable.
2016-10-24 13:06:25 -07:00
Slava Pestov
dec05e14e1 Sema: Simplify substMemberTypeWithBase()
The isTypeReference parameter is now always true, so change
the function to just take a TypeDecl.
2016-10-24 02:16:20 -07:00
Slava Pestov
0bc3dec954 Sema: New TypeBase::adjustSuperclassMemberDeclType() method
This generalizes some code in Sema to fix the problem where
generic method overrides don't work if the base class is
more or less generic than the derived class.

The problem here was that we were checking types for equality
when matching overrides, which failed if generic parameters
had different depths. Now, map the generic parameters of the
base class member to the generic signature of the derived
member, so that the equality check can succeed.

Since SIL type lowering needs to perform a similar check,
move this from Sema to a method on TypeBase to complement
the existing getTypeOfMember().

Note that getTypeOfMember() still does a superclass walk, but
ideally this will go away soon.
2016-10-24 02:16:20 -07:00
Doug Gregor
cf19b8a76b [Constraint solver] Eliminate addConstraint(Constraint*).
We no longer build constraints just to immediately simplify them.
2016-10-23 22:27:33 -07:00
Doug Gregor
d4f5c72c1e [Constraint solver] Only build disjunctions when they're unsolved. 2016-10-23 22:27:33 -07:00
Doug Gregor
7f6654001b [Constraint solver] Handle 'bind' constraints lazily. 2016-10-23 22:27:33 -07:00
Doug Gregor
50cb31c5c4 [Constraint solver] Make 'defaultable' constraint creation lazy. 2016-10-23 00:15:50 -07:00
Doug Gregor
1b8d4399f3 [Constraint solver] Make optional object constraint construction lazy. 2016-10-23 00:15:50 -07:00
Doug Gregor
12b6894849 [Constraint solver] Address some of Mark's comments. NFC 2016-10-22 23:27:41 -07:00
Doug Gregor
d2cb83b4c7 [Constraint solver] Make checked cast constraint generation lazy.
Fixes rdar://problem/27148148.
2016-10-22 22:57:25 -07:00
Doug Gregor
af4d44e013 [Constraint solver] Lazily handle conformance-related constraints.
The code was already there for them; make sure we use it
consistently.
2016-10-22 22:20:03 -07:00
Doug Gregor
8451536e89 [Constraint solver] Lazily allocate DynamicTypeOf constraints. 2016-10-22 22:20:03 -07:00
Doug Gregor
ed71fd08c3 [Constraint solver] Lazily construct ApplicableFunction constraints. 2016-10-22 22:20:03 -07:00
Mark Lacey
755ee37cc1 Fix a latent bug in Constraint::clone().
Noticed by inspection.
2016-10-21 16:43:02 -07:00
Doug Gregor
41cd760682 [Constraint solver] Clean up existential metatype handling.
Our existential metatype conversion/conformance handling in the type
checker was tripped up the refactoring to lazily introduce
constraints, because it dependended on the otherwise-unused
TypeMatchKind::ConformsTo. Eliminate TypeMatchKind::ConformsTo and
simplify the code here.
2016-10-21 14:31:11 -07:00
Doug Gregor
7519d83007 [Constraint solver] Start lazily building relational constraints.
Start migrating the main ConstraintSolver::addConstraint() entrypoint
for relational constraints over to the model where it simplifies
first, then only creates a new constraint if the constraint it built
cannot be solved. This covers only the main relational
constraints--there are a number of other relational constraint kinds
to handle this way.
2016-10-21 14:03:56 -07:00
Doug Gregor
bdd27e9982 [Constraint solver] Lazily generate member constraints.
When adding a new member constraint, try to immediately simplify it,
generating a constraint when it cannot be resolved. Note that we also
generate constraints in top-level failure cases, so that the
diagnostics machinery can find it after-the-fact.
2016-10-21 14:03:56 -07:00
Doug Gregor
a5ec531cd0 [Constraint solver] Teach addBindOverloadConstraint to simplify directly.
We never have to allocate BindOverload constraints, so don't.
2016-10-21 14:03:56 -07:00
Doug Gregor
337558dcb9 [Constraint solver] Allocate 'restricted' constraints lazily.
When adding a 'restricted' constraint, go straight into the 'simplify'
operation. A new constraint will only be allocated and recorded if it
cannot be immediately simplified. To get here, be more rigorous about passing TMF_GenerateConstraints through simplifyRestrictedConstraint().
2016-10-21 14:03:56 -07:00
Doug Gregor
a4fc0aaad2 [Constraint solver] Don't reprocess constraints known to be unsolvable.
When we're creating a new constraint because we couldn't solve it (and
need to record the result), do so without trying to simplify it yet
again. It's just wasted work.
2016-10-21 14:03:56 -07:00
Doug Gregor
b69d01eef2 [Constraint solver] Remove unused 'class' constraints. NFC
We're not using these now. Someday, maybe, but it will be easy to
bring back this code if we find that we need it later.
2016-10-21 14:03:56 -07:00
Doug Gregor
483dfdcaa1 [Constraint solver] Remove 'archetype' constraint kind. NFC
Archetype constraints haven't been needed since we implemented SE-0091.
2016-10-21 14:03:56 -07:00
Doug Gregor
14a4fdbc50 [Constraint solver] Use OptionSet rather an 'unsigned'. NFC 2016-10-21 14:03:56 -07:00
Doug Gregor
beadfc774b [Constraint solver] Eliminate unused parameters to addConstraint().
ConstraintSystem::addConstraint() is no longer used to simplify
existing constraints, nor does it have to deal with "externally
solved" constraints. Remove those parameters and simplify the code. NFC
2016-10-21 14:03:56 -07:00
Doug Gregor
e094adb50a [Constraint solver] Use custom addConstraint entrypoints consistently.
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
2016-10-21 14:03:56 -07:00