If we used the requirement signature to create a protocol requirement
element in a requirement source, there's no need to verify that it's
from the requirement signature (duh).
The Swift class model does not support overriding declarations where either
the overridden declaration or the overriding declaration are in an extension.
However, the Objective-C class model does, so marking the declaration as
@objc (when possible) will work around the limitation.
Customize the "cannot override declaration in extension" diagnostic to
suggest adding @objc to the overridden declaration in cases where
@objc is permitted. Fixes SR-6512 / rdar://problem/35787914.
This presents a regression in diagnostic quality that is definitely
worth it not to lie to SILGen about whether a switch is covered or not.
At the same time, disable SIL’s unreachable diagnostic for ‘default’
clauses which would previously cause a warning to be emitted if the
default was proven to be unreachable. This analysis is incomplete
anyways and can be done by Sema in the future if we desire.
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.
