There is no need to keep SILModules around after IRGen has generated LLVM IR from them.
This reduces the compiler memory usage during LLVM code-generation and optimization phases roughly by 15%-20%.
The Swift compiler uses files with an extension of ".swiftdeps" to store
information about cross-file dependencies. These files are read in at the
start of compilation to compute a dependency graph, and updated as compilation
proceeds. However, because these files are updated on every build, an
issue with dependency analysis is hard to reproduce—the inputs have been
lost.
Address this by renaming swiftdeps files that are about to be
overwritten, to '.swiftdeps~'. This preserves dependency information
from the most recent compilation (but no further back).
Enables Chris's auto-apply-fixes mode for -verify: if an expected-*
annotation has the wrong message, or if the expected fix-its are
incorrect, this option will **edit the original file** to update them.
This is a tool for compiler developers only; it doesn't affect
normal diagnostic printing or normal fix-its.
Introduce an operation that produces the set of local declarations
that are newly introduced by a given AST scope. This is a building
block of unqualified name lookup, which walks upward in the tree
(e.g., from children to parents) looking for declarations that have
been made visible at each step.
Given a source location, we can find the innermost enclosing scope
that describes that source location. Introduce this operation into the
scope map, then add a testing mode where we probe the scope map at
specifi locations to see what we find. Test for:
1) Finding the right innermost enclosing scope, and
2) That we're only expanding the part of the scope map that is needed
to identify that scope.
The scope map models all of the name lookup scopes within a source
file. It can be queried by source location to find the innermost scope
that contains that source location. Then, one can follow the parent
pointers in the scope to enumerate the enclosing scopes.
The scope map itself is lazily constructed, only creating scope map
nodes when required implicitly (e.g, when searching for a particular
innermost scope) or forced for debugging purposes.
using a lazily-constructed tree that can be searched by source
location. A search within a particular source location will
And improve the error message for non-empty braces; if we're going to
ignore the contents, we should at least point you in the right
direction for Swift 3.
rdar://problem/27576922
This fixit comes from a note, but is very useful for migration of code
that has changed from AnyObject to Any but wants to do AnyObject
dispatch.
rdar://problem/27793389
We added the fixit to help users manually migrate enum case references after the declaration
has been renamed; however, when interacting with the migrator, the fixit may revert migrator's
correct changes, when the migrator updates references before updating the declaration. This patch
blacklists the fixit in migrator's pass, so we leave it to users' manually application if necessary.
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
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
These are very useful fixits for migration. Note: this applies the
fixits for selectors that are actually found, but not the one that wraps
an arbitrary string literal in Selector(...), because that one indicates
a possibly missing selector that the user should review.
rdar://problem/26678232
Now that we have ArchetypeBuilder::mapTypeOutOfContext(), we can
delete some tricky hand-crafted logic for getting the depth and
index of archetypes.
Notice that the depth of an archetype is now the same as generic
parameters, where depth 0 is the outermost generic context.
Previously it was backwards.
Mostly NFC, except that a few IDE crashers are now fixed because
of asserts firing in removed code, and also the change to depth
mangling (which I think makes sense, and it matches what's written
in docs/ABI.rst).
These interact badly with the swift migrator, they are triggered by label mismatches in pre-migrated code.
We also don't generally need them since we do inference for the most common cases.
