Now that WitnessChecker is separate from ConformanceChecker, implement
a DefaultWitnessChecker subclass which performs default witness
resolution.
This populates the recently-added ProtocolDecl::DefaultWitnesses map.
Unlike ConformanceChecker, the DefaultWitnessChecker looks up the witness
in any protocol extensions of the protocol, matching the context archetypes
of the requirement against the witness.
For now, we infer default witnesses for all protocols, but don't do
anything with that information. An upcoming SILGen patch will start to
emit thunks and add tests.
Fills in Chris's placeholder in feace85d5. I'm not quite sure why a private
subscript doesn't produce a non-cascading dependency right now, but this is
at least conservatively correct.
(For more infomation on dependencies, check out "Dependency Analysis.rst".)
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
Also, checking protocol conformances doesn't depend on any members, just the type.
We don't track dependencies on types separately from members right now, though,
so instead there's now a dummy dependency on 'deinit'.
Swift SVN r30288
There's now a difference between "this file provides a particular type" and
"this file provides members on a particular type". Adding a conformance in
an extension is still considered "providing a type" because it can affect
things besides just lookups.
This modifies the swiftdeps file output (including the members used by a file),
but the driver hasn't been updated to take advantage of this yet.
Swift SVN r30285
- (depends|provides)-top-level for top-level names.
- (depends|provides)-nominal for access into nominal types.
- (depends|provides)-dynamic-lookup for @objc members available on AnyObject.
- depends-external for cross-module file-based dependencies.
No functionality change.
Swift SVN r30283
My 'declIsPrivate' predicate was too conservative: it saw a PatternBindingDecl,
didn't know what it was, and decided that meant it might not be private. Now it's
actually checking the decl kind and doing something reasonable for non-ValueDecls.
Swift SVN r30282
I think this is all working fine: we already say that a type adopting a
protocol depends on that protocol's members, and that an extension of a
protocol can supply members. It's a pretty conservative mechanism since
it doesn't take the constraints into account, but that's okay for now.
rdar://problem/20476867
Swift SVN r28475
Instead, just check the generic parameters, then do a lookup as usual in the
enclosing context.
Fixes crash suite #58 and quite a few others (~200). This looks way more
impressive than it is; in most of these test cases it's the exact same
pattern causing the crash, and that pattern was just the last outstanding
crash trigger in a sea of garbage. (The few deleted tests were identical
to #58.)
Swift SVN r24748
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
If a conformance is found for a type in another module, that conformance
will never change in response to what happens in this module, so we don't
need to treat it as a dependency at all.
Swift SVN r23702
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
...and thus does not affect downstream files...
...and adopt it in several places:
- when looking up the default type for a literal (test included)
- when looking up the first component in an IdentTypeRepr (test included)
- when deciding which ~= to use in a switch (test forthcoming)
- when a protocol has an operator function requirement (test forthcoming)
- when validating @NSApplicationMain and @UIApplicationMain
- when an enum element shows up unqualified in a switch
- several places where it doesn't matter because we're looking something up
in the standard library.
Part of rdar://problem/15353101
Swift SVN r23670
Extensions of private types can't affect anything outside the current file,
so we shouldn't treat them as having cascading dependencies on protocols
they add conformances for. However, the previous commits didn't actually
make sure we'd computed an extension's default access by the time we start
checking its conformances.
Swift SVN r23634
This adds a check to isPrivateContextForLookup, and also changes Sema to
use a function itself as the lookup context for non-generic functions'
result types (like generic functions already do). It also moves
isPrivateContextForLookup onto DeclContext itself, to be used in the next
commits.
Swift SVN r23633
This adds a new parameter to TypeChecker::lookupMember to specify when
something is known-private, which can then be passed along to
DeclContext::lookupQualified. This makes many of the existing member
lookup dependencies in the reference-dependencies.swift test correctly
count as private.
Swift SVN r23631
This adds a new flag TR_KnownPrivateDependency, which is a bit stronger than
TR_InExpression. The latter only results in private dependencies when the
decl context is a function, or when the context is otherwise private.
Swift SVN r23524
Again, expression contexts are those that can't show up in a function
signature, so type resolution in a function decl context can assume
that all resulting type dependencies are private.
Swift SVN r23523
This commit treats all TypeExprs and casts as private if the decl context
is a function. In other cases we fall back to the general rules about the
current context (from r23447).
Swift SVN r23522
Previously we were using the enum itself as the decl context to look up
enum members in switch case patterns. This meant that we weren't respecting
access control rules (not an issue, since enum cases currently don't have
access control), nor recording the dependency on the enum (oops).
Swift SVN r23521
This is the start of distinguishing qualified lookups within function bodies
from qualified lookups in a function signature. Both of these use the
function itself as the decl context, so we need to distinguish them manually.
This particular commit doesn't change much because expressions don't often
use TypeMember constraints. But it does help with for-loops!
Swift SVN r23484
