For now, just update NameLookup's FindLocalVal to use a
VisibleDeclConsumer just like lookupVisibleDecl().
A subsequent patch will continue removing duplicated code
now that this is place.
This fixes compiler crashers where we were not handling
declarations with duplicate names (which of course is an
error, diagnosed elsewhere).
Swift SVN r29913
- NominalTypeDecl::computeInterfaceType() crash when parent decl
has error type
- createMaterializeForSetPrototype() crash when parent decl
has error type
- Crashes in ConformanceChecker when decl has error type
Fixes <rdar://problem/21583601>.
Swift SVN r29912
All archetypes from outer scopes are fixed (as a lame implementation
restriction), so same-type constraints that involve archetypes from
outer scopres should treat the archetypes from outer scopes as the
representative. Do so, and start eliminating the notion of a "primary"
archetype that was preventing this fix from occurring earlier, so that
"all archetypes" and the set of requirements generated from the
archetype builder still line up.
Fixes rdar://problem/19519590.
Swift SVN r29869
ExtensibleCollectionType's operations can all be represented by the
primitive range replacement operation, so fold it into
RangeReplaceableCollectionType.
In addition, provide default implementations of
RangeReplaceableCollectionType's methods.
- New tests added for combinations of (static, generic) calls and
(default, custom) implementations.
- Mark free Swift functions as unavailable with a message to direct the
developer to the protocol methods.
- Mark ExtensibleCollectionType as available with a message added to
direct the developer to the right protocol.
rdar://problem/18220295
Swift SVN r29857
We were doing piecemeal checking of the requirements of specific
associated type bindings, but such checking is incomplete: superclass
constraints and, although currently inexpressible, same-type
constraints are not validated by these early checks, so this is more
correct and more robust.
Swift SVN r29808
Previously, we were simply walking over the requirements of each of
the associated types, which meant that we weren't considering
same-type constraints. Also cleans up the diagnostics a little bit and
eliminates some extra computation whose results were getting thrown
away.
Swift SVN r29793
- In name lookup, if we find a decl that is already being type checked
(which only occurs on illegal code) just assume it is acceptable instead
of blowing up with an assertion checking access control that hasn't been
evaluated yet.
- In checkInheritanceClause, make sure that the we mark the decl being
resolved as being type checked when resolving the types involved. That way,
cyclic references are detected as invalid, instead of causing assertions and
other explosions.
This fixes some compiler crashers.
Swift SVN r29538
init()'s implicitly evaluate the initial values for properties, and we aren't modeling
that correctly in the AST. This prevented the closure checker from noticing these
accesses, leading to SILGen crashing later. In the absence of proper AST modeling of
this, add special case handling for them.
Swift SVN r29508
Previously the placement of the OpenExistentialExpr was determined
entirely from the natural argument count of the function.
There was a hack to add any missing OpenExistentialExprs at the top
level, but this didn't work if the method had a Self return value
and there were intermediate expressions, eg, if someMethod has a
Self return, foo(anExistential.someMethod) would generate a
diagnostic about open existentials.
Change ExprRewriter to use a new existential placement algorithm
that instead walks up the expression stack to determine the outermost
function application of an existential base, and insert the
OpenExistentialExpr there.
Progress on <rdar://problem/21289579>.
Swift SVN r29448
We were using getRValueType() and getRValueObjectType() when
setting up the constraint, but getRValueType() when simplifying
it. This led to a crash if the type was a single-argument tuple
with a named argument.
Swift SVN r29376
X.Protocol is an instance of Y.Type only if X conforms to Y. Since X
is a protocol, this is only true if X contains Y and Y is
self-conforming.
Note that this updates some tests that actually contained invalid code.
Fixes <rdar://problem/20915927>.
Swift SVN r29349
Rename existentialConformsToSelf() to existentialTypeSupported(). This
predicate is the "protocol has no Self or associated type requirements"
check, which is a looser condition than self-conformance. This was being
tested to see if the user could refer to the protocol via an existential
type.
The new existentialConformsToSelf() now checks for protocol being @objc,
and for the absence of static methods. This is used as part of the
argument type matching logic in matchType() to determine if the
existential can be bound to a generic type parameter.
The latter condition is stricter, for two reasons:
1) We allow binding existentials to multiple type parameters all sharing
the same generic type parameter T, so we don't want the user to be
able to see any static methods on T.
2) There is an IRGen limitation whereby only existentials without witness
tables can be passed in this manner.
Using the above, the representsNonTrivialGenericParameter() function
has been renamed to canBindGenericParamToExistential(). It now allows
an existential type to be bound to a generic type parameter only under
the following circumstances:
A) If the generic type parameter has no conformances, the match is allowed.
B) If the generic type parameter has at least one conformance, then all
of the conformances on the generic type parameter must be
existentialConformsToSelf() (condition 1 above), and all conformances
on the existential must be @objc (condition 2 above).
Fixes <rdar://problem/18378390> and <rdar://problem/18683843>, and lays
the groundwork for fixing a few other related issues.
Swift SVN r29337
The last remaining case was apparently @objc generic classes, which
seem to work now.
Also nuke the IRGen/unimplemented_objc_generic_class.swift test,
this is now implemented and we have other tests that test this
functionality.
Swift SVN r29260
Resolves a few compiler crashes on invalid. One could imagine this
triggering on well-formed code, but I was unable to form such a test
case.
Swift SVN r29149
The last remaining case was apparently @objc generic classes, which
seem to work now.
Also nuke the IRGen/unimplemented_objc_generic_class.swift test,
this is now implemented and we have other tests that test this
functionality.
Swift SVN r29138
We only attempt to access such nested types in ill-formed code, but
this helps maintain AST invariants. Fixes rdar://problem/20593294 and
resolves 18 compiler crashers.
Swift SVN r29135
The aforementioned commit didn't really fix the problem, but it happened
to avoid the crash, so I've tweaked the tests to continue crashing. In
order to keep in sync with upstream practical swift, I renamed the
tweaked tests and copied the original ones into "fixed".
Swift SVN r29033
Rather than always using depth 0 for the Self generic type parameter
of a protocol, which is the correct value in well-formed code,
actually compute the depth based on the context. This maintains the
depth invariants of the AST in ill-formed code, resolving a large
number of crashers (169), including rdar://problem/21042357, and
regresses one crasher.
Swift SVN r28920
This reverts revision r28480, after mailing list discussion it is
agreed that this is a bad idea.
Note that a test had to be updated adding a new expected warning.
Swift SVN r28515
Properly implementing a class whose methods capture variables
defined in the outer scope requires adding the captures as
hidden vars in the class and initializers, and seems
non-trivial.
Just diagnose this case for now instead of crashing.
Fixes <rdar://problem/20853958>.
Swift SVN r28481
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
When performing unqualified lookup within a type context (or method
thereof) that is a protocol or a protocol extension, use the Self
archetype of the protocol or extension so we look in types implied by
the requirements as well. Part of rdar://problem/20509152, fixing the
example provided in rdar://problem/20694545.
Swift SVN r28363
Members of protocols found via unqualified name lookup are mapped to
their corresponding witnesses, as we do for qualified name
lookup. This is the bulk of the compiler changes for
rdar://problem/20509152. Performing this mapping for unqualified name
lookup of types will follow.
Swift SVN r28333
The code would generate different diagnosics depending on
the cycle having length 1 or longer. The length 1 case
was broken if the path had a prefix that wasn't part
of the cycle, eg if we have C : A, A : A and visit C
first.
Swift SVN r28317
