We still do a global lookup for operators even though they are
syntactically declared within types now, so for dependency-tracking
purposes continue to treat that as declared at the top level.
This isn't where we actually want to be---ideally we can use the types
of the arguments to limit the dependencies to a member lookup (or pair
of member lookups)---but since the operator overloads /themselves/
participate in type-checking an expression, I'm not sure that's 100%
correct. For now, it's better to be conservative. (This means
dependency analysis for operators remains as lousy as it was in Swift
2, but it's not a regression.)
rdar://problem/27659972
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
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".)
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
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 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
This does reveal an overly conservative case: lookup in the inheritance
clause of extensions is always considered a non-private lookup, even if
it's extending a private type, because we haven't yet resolved what it's
extending. Won't lead to incorrect behavior, just more compilation than
is strictly necessary.
Swift SVN r23481
This is sort of two commits squashed into one: first, update
ReferencedNameTracker to record whether a name or type is non-private,
along with changing all clients to assume non-private; and second,
actually try to (conservatively) decide if a particular unqualified lookup can
be considered private.
What does "private" mean? That means that a dependency does not affect
"downstream" files. For example, if file A depends on B, and B depends on C,
then a change in C normally means A will get rebuilt. But if B's dependencies
on C are all private dependencies (e.g. lookups from within function bodies),
then A does not need to be rebuilt.
In practice there are several rules about when we can make this assumption,
and a few places where our current DeclContext model is not good enough to
distinguish private uses from non-private uses. In these cases we have to
be conservative and assume that the use is non-private (and thus that
downstream files will need to be rebuilt).
Part of rdar://problem/15353101
Swift SVN r23447
This isn't so interesting because we already depend on the top-level name
of a protocol, but it becomes more interesting if/when we start allowing
protocol extensions.
Part of rdar://problem/15353101
Swift SVN r23392
We need to do this mainly to figure out when extensions can affect this file.
This is part of the intra-module dependency tracking work to implement
incremental rebuilds.
Part of rdar://problem/15353101
Swift SVN r22927
Every name a file declares is something that another file in the same module
might depend on. The driver will need this information too to correctly
decide what files need to be rebuilt. This is part of the intra-module
dependency tracking work to implement incremental rebuilds.
This doesn't handle extensions yet, which are a bit trickier. Need to
figure out how to handle the interaction between extensions and typealiases.
Part of rdar://problem/15353101
Swift SVN r22926
This tracks top-level qualified and unqualified lookups in the primary
source file, meaning we see all top-level names used in the file. This
is part of the intra-module dependency tracking work that can enable
incremental rebuilds.
This doesn't quite cover all of a file's dependencies. In particular, it
misses cases involving extensions defined in terms of typealiases, and
it doesn't yet track operator lookups. The whole scheme is also very
dependent on being used to track file-level dependencies; if C is a subclass
of B and B is a subclass of A, C doesn't appear to depend on A. It only
works because changing A will mark B as dirty.
Part of rdar://problem/15353101
Swift SVN r22925
