It can be quite difficult to tell at a glance just how any particular decl is going to be converted into a key. The space of available template specializations is also 2-dimensional which adds an additional level of difficulty when the time comes to extend or refactor any of them. Unroll all of the templates into a builder that coalesces the commonalities of the ways DependencyKeys are built to combat this.
Remove this distinction without a difference. Originally, the thought
was to
1) Isolate the cross-module build infrastructure
2) Provide a signal to the driver that a dependency had swiftdeps info
in it
But the driver need only notice swiftmodule files as external
dependencies and try to extract that information if it can to divine the
signal it needs. Additionally, we can give it fingerprints as priors to
let it know there might be incremental info to be had.
Switch from a string core to a 128-bit integral core. This should make
Fingerprints much cheaper to copy around and sets us up for a future
where we can provide alternative implementations of the ambient hashing
algorithm.
rdar://72313506
ELF is sensitive to library ordering. Ensure that `swiftClangImporter`
comes after `swiftAST` as `swiftAST` has grown a dependency on
`swiftClangImporter`. Adding this properly using
`target_link_libraries` will cause a cyclic dependency so add this
reordering here.
If file A extends a common type (say, Dictionary), but only adds new members,
other files using Dictionary don't need to be recompiled if they definitively
don't use those members. That should be working now.
Swift SVN r30286
- (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
We don't actually check them yet, but this fits them into the same dependency
structure as intra-module dependencies.
Part of rdar://problem/19270920
Swift SVN r24335
...and some basic unit tests for it.
The purpose of this class is to track dependencies between opaque nodes.
The dependency edges are (kind, string) pairs, where the "kind"
distinguishes different kinds of dependencies (currently "top-level names"
and "types that we do lookup on"). The step is to make use of it in
running compile commands.
The YAML-based file format is only for bring-up and testing purposes.
I intend to switch it to a bitcode-based format in the long run.
Part of rdar://problem/15353101
Swift SVN r23223
