Move the rest of associated type inference into the new source file,
and split RequirementEnvironment into its own AST-level header, because it
can be re-used and has no ties to the type checker.
There is nothing specifically wrong with uttering a same-type
constraint in a where clause where both sides are concrete
types. Downgrade this to a warning; we'll check that the concrete
types match (of course), and such a well-formed constraint will simply
be canonicalized away.
This aids the migration of IndexDistance from an associated type to
Int.
Previous versions of Swift accidentally treated lazy properties as
computed properties because of how they were implemented. Now that we
check this correctly, we've broken source compatibility. Downgrade the
error to a warning in this case.
(Arguably we could /allow/ overriding with a stored property. The
original concerns were that you could accidentally end up with extra
storage you didn't need, and that observing accessors would behave
differently based on whether or not the property was overriding. But
there's at least no ambiguity for 'lazy', which can't have observing
accessors today.)
rdar://problem/35870371
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
Instead, just emit a deprecation warning and suggest switching to Optionals.
The old behavior caused several projects to break, so before we change
the behavior here we need to investigate whether we can mitigate most
of those breaks.
The empty sentinel in the lookup table caused recursion-breaking to bottom
out in slightly different order than the old eager code, making certain
order-sensitive tests fail.
1) TypeKind only needs six bits at the moment, so this leaves us with
plenty of room for additional type kinds.
2) While the size of TypeBase does not change, there are many more bits
available for subtypes to use.
The empty sentinel in the lookup table caused recursion-breaking to bottom
out in slightly different order than the old eager code, making certain
order-sensitive tests fail.
Right now if convert_function is used incorrectly by SILGen, we get an error via
the SILVerifier after we have finished building the entire function. This is a
pain in the butt to track down. Using this refactor, I am able to just assert in
the SILBuilder itself.
On another note, down the line we should just separate the dataflow checker part
of the verifier from specific SILInstruction verification. This would allow for
SILBuilder to perform the SILInstruction verification upon creation giving the
same effect. Such a change is a much larger change though and this is just a
commit chopped off a larger commit.
rdar://34222540
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
