But not even that much uglier; at all three call sites this will save
an allocation, and for the most important one (SourceKit) we can now
avoid creating a temporary CompilerInvocation just to copy into a
longer-lived one.
With this change, Driver no longer depends on Frontend, which means...
well, slightly faster builds of the compiler itself, but not much
else.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
The recommended way forward is to use the SyntaxClassifier on the Swift
side.
By removing the C++ SyntaxClassifier, we can also eliminate the
-force-libsyntax-based-processing option that was used to bootstrap
incremental parsing and would generate the syntax map from a syntax
tree.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
instead of using name and decl context.
The advantages of this approach are three-fold:
- This is necessary to support inlined generic functions.
- We can retire the debugger-specific type name manfgling mode for archetypes.
- This saves 270kb of debug information in the x86_64 libSwiftCore.dylib alone.
<rdar://problem/38306256>
The importer in particular depends on the stdlib and the Foundation
overlay being successfully loaded, so if anything /can't/ be loaded
we have to assume that trying to walk a module's decls will result
in a crash.
rdar://problem/37540394
Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
Before this patch, we have one flag (KeepSyntaxInfo) to turn on two syntax
functionalities of parser: (1) collecting parsed tokens for coloring and
(2) building syntax trees. Since sourcekitd is the only consumer of either of these
functionalities, sourcekitd by default always enables such flag.
However, empirical results show (2) is both heavier and less-frequently
needed than (1). Therefore, separating the flag to two flags makes more
sense, where CollectParsedToken controls (1) and BuildSyntaxTree
controls (2).
CollectingParsedToken is always enabled by sourcekitd because
formatting and syntax-coloring need it; however BuildSyntaxTree should
be explicitly switched on by sourcekitd clients.
resolves: rdar://problem/37483076
Before conditional conformances, the archetypes in conformance
extensions (i.e. extension Foo: SomeProtocol) were equivalent to those
in the type decl, with the same protocol bounds and so on. The code for
printing "synthesized" members relied on this fact. This commit teaches
that code to deal with archetypes in the conditional conformance
extension when required.
Fixes rdar://problem/36553066 and SR-6930.
[ClangImporter] Make sure that headers from the bridging header are considered 'isBeforeInTranslationUnit' compared to headers imported from swift code
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
Note that this /still/ isn't correct when there /isn't/ an explicit
target, because LangOptions doesn't set up platform conditions when no
target is explicitly set. But it's a step forward.
ClangImporter::lookupTypeDecl allows a Clang type declaration to be
imported by Clang name instead of by Swift name. Now that we're using
Clang names in mangled names, that's exactly what we need to
reconstruct an AST type from a mangled name.
Also:
- Handle @compatibility_alias in ClangImporter::lookupTypeDecl
- Print errors when type reconstruction fails in swift-ide-test
- Add an extra test for RemoteAST
The original hope was we could make these heuristics really good, but
since that is not currently in sight (and may never be), we want to be
able to turn them off. For now, just plumb through an internal flag to
control the behaviour. A future change will customize the behaviour in
SourceKit.
rdar://31113161
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
