Right now we just have one notion of providing or using a type (as opposed to a
name). It doesn't matter if you're doing lookups, or checking conformance, or
inheriting from a superclass or protocol -- they're all in the same bucket. I'd
like to split these out so that extending a commonly-used type (like, say, Array)
doesn't cause every file in your target to depend on your extension.
This commit doesn't do anything but start tracking which member names are looked
up. For the other things you can do with a type, it's using a dummy empty name.
Swift SVN r30284
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
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
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
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
