By default, the frontend tries to figure out if the built module is
likely to be distributed in some way, and uses that to decide whether
to include options that help with debugging (such as local search
paths). There's long been a -serialize-debugging-options that forces
those options to be included even when it looks like a framework is
being built, but the opposite has been absent until now.
Note that both of these options are still /frontend/ options, not
driver options, which means they could still change in the future.
(I'd really like to get to a point where debugging doesn't need to
sniff these options out from the module this way, but there are some
complications we'd need to work out. Swift 1 expediency coming back to
cause trouble again.)
rdar://problem/37954803
This diagnostic needs to be adapted for swiftinterfaces too, but
meanwhile let's not have it get in the way when dealing with a
multi-architecture module that has parseable interfaces.
MyKit.framework/
Modules/
MyKit.swiftmodule/
x86_64.swiftinterface
x86_64.swiftdoc
# no x86_64.swiftmodule
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
Otherwise, we can't represent a cross-reference to generic parameters
in a parent type /when used in an extension/.
https://bugs.swift.org/browse/SR-9084
This file is very specifically counting the number of declarations
that get deserialized under a certain scenario, and so it's not really
the place to add tests for other things about cross-references and
extensions.
Previously, the fast path for nested types only worked when the nested
type was defined in a Swift module or a Clang module without an
overlay; this is because it was originally designed to fix circularity
issues when merging partial modules for a single target. By having a
Swift overlay module pass through requests for nested types to the
underlying Clang module, we get the fast-path behavior in more cases.
(The one case where it /won't/ kick in is if the overlay has a nested
type that shadows a nested type from the Clang module, but that's
probably pretty rare!)
This commit allows the initial switch subject value to be emitted at +0 if we
can emit it that way. As you can imagine since we have +0 normal function
arguments this should tighten up a lot of code around switches on arguments. So
I got to delete a bunch of code in the tests. = ).
Some things to note:
1. If the switch is given a +1 value, we will still try to let it through at +1
until we hit a part of the decision tree where previously we would need to use
TakeOnSuccess. This means that +1 values that go through irrefutable patterns
like tuple splitting should still be emitted at +1.
2. If we are returned an address only type without a cleanup, we copy it and
pass it down at +1 like the old code.
3. I also elided the last ownership check in SILGenPattern in this commit. After
this, there is only 1 specialization for ownership in the swift compiler that is
in Apply emission. Thats my next target.
rdar://29791263
The goal here is for the SILGen of these builtins to receive an owned
value so that it will perform an owned->owned conversion and therefore
produce a +1 result, as generally expected. Without this, SILGen will
perform a borrowed->borrowed conversion, and the copy of the result (if
it even happens) may happen after the argument's borrow scope has ended.
We should have the LLVM build which provides most of the tools that we need.
`strings` is amongst them. Add a new `llvm-strings` substitution from lit and
use that instead of `strings`. This helps with Windows which does not have a
`strings` tool.
Generic environments and archetypes can be expensive to deserialize
if they involve a generic signature not seen before.
Also, canonicalize the witness substitutions to eliminate type
aliases, and map them to interface types, which again are cheaper
to deserialize.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
Swift currently checks if an imported module has a deployment target
compatible with what’s currently being compiled. For a resilient
module, though, you really want to know the /oldest/ deployment target
the library supports, not the one it was most recently compiled with,
and we don’t currently save that information. Disable this check for
now when the module is resilient.
(Why not do this on the serialization side? Because the deployment
target you compile with is still relevant when trying to match the
compilation environment as closely as possible, which LLDB tries to
do. It's also just useful information for debugging the compiler.)
rdar://problem/42903218
The recovery logic was erronously kicking in, because it was comparing
the substituted underlying type with the declaration's underlying type.
For a generic typealias, these never equal, so instead, serialize the
unsubstituted type, and substitute it in deserialization.
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.
This isn't just an optimization; we weren't recording that the
attribute was invalid, and so it was getting /treated as valid/ when
the module was imported into a client later.
This would have caught the issue fixed by the previous commit.
Actually, the biggest win here seems to be not recording parameters,
which were taking up a ridiculous amount of space in the generated
swiftdoc. This change takes Swift.swiftdoc from 5MB to 3.5MB.
This allows us to dump it in the generated interface, though it's
still not syntax-highlighted. This is necessary for textual module
interfaces, but it's also just a longstanding request for Xcode's
"Generated Interface" / "Jump to Definition" feature.
rdar://problem/18675831
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
Before:
module file's minimum deployment target is iOS 12.0:
/path/to/FooKit.swiftmodule
After:
compiling for iOS 11.0, but module 'FooKit' has a minimum deployment
target of iOS 12.0: /path/to/FooKit.swiftmodule
Also tweak the "incompatible target" error to include the module name.
rdar://problem/35546499
We previously shied away from this in order to not /accidentally/
depend on it, but it becomes interesting again with textual
interfaces, which can certainly be read by humans. The cross-file
order is the order of input files, which is at least controllable by
users.
This is how we originally controlled whether or not we printed out ownership
annotations when we printed SIL. Since then, I have changed (a few months ago I
believe) the ownership model eliminator to know how to eliminate these
annotations from the SIL itself. So this hack can be removed.
As an additional benefit, this will let me rename -enable-sil-ownership to
-enable-sil-ownership-verifier. This will I hope eliminate confusion around this
option in the short term while I am preparing to work on semantic sil again.
rdar://42509812
If, for whatever reason, a type used in an extension's generic
requirements is missing, just drop the whole extension. This isn't
wonderful recovery, but in practice nothing should be able to use the
extension anyway, since the relevant type in question is missing.
...Okay, that's not quite true; there could, for example, be inlinable
code that references one of these methods. However, that (1) isn't
worse than the behavior for any other inlinable code (which doesn't
yet attempt to recover from missing declarations), and (2) is still a
strict improvement over the current situation, where we will eagerly
abort the compiler trying to load the extension in the first place.
rdar://problem/40956460
Previously: "module compiled with Swift 4.1 cannot be imported in Swift
4.1.50" (i.e. following the -swift-version flag)
Now: "module compiled with Swift 4.1 cannot be imported by the Swift
4.2 compiler"
I'm pretty sure this is what I intended to do all along, and I just
messed it up when I originally implemented it. This is especially
important when working with downloadable toolchains, which would say
"module compiled with Swift 4.2 cannot be imported in Swift 4.1.50",
which is not really the problem at all. Now it'll fall back to the
more generic "module file was created by an older version of the
compiler" error.
