We use dummy symbols to force overlays not to get dropped when
autolinking, even if the user doesn't use anything from them
explicitly. This behavior is triggered by the semi-hidden flag
-autolink-force-load.
(It's semi-hidden because it has few legitimate uses in real life. If
you searched for "how to force autolinking to pick up a library" and
found this commit, don't just do this and move on. Come talk to me on
forums.swift.org.)
Previously we added these dummy symbols to every object file using
"common" linkage, a little-known feature added for C that ensures that
only one definition will actually get used in the final object file.
However, the way we were doing that wouldn't work so well for COFF,
and so in 1025eed64 Saleem changed this to use "weak ODR" linkage.
This has *nearly* the same effect, and avoids some other weirdness,
but has the downside of making the symbol in the final dylib "weak"
itself, meaning that some /other/ library could come along and
override it. That impacts loading time, and an Apple-internal tool
caught that as rdar://39019606.
To avoid this whole mess, "just" emit the symbol into the object file
that corresponds to the first file in the module, which allows us to
mark it as a normal public symbol.
P.S. None of this is actually important at the moment because all of
the overlays are built with single-threaded WMO, which always produces
one object file anyway. But I wanted to get it right once and for all.
Add serialization layouts for rare instructions that take extra attributes. We
can continue adding bits to these layout without affecting the layout of the
vast majority of instructions.
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
I am going to leave in the infrastructure around this just in case. But there is
no reason to keep this in the tests themselves. I can always just revert this
and I don't think merge conflicts are likely due to previous work I did around
the tooling for this.
(currently spelled with an underscore to indicate its WIP state)
Later commits will handle imported enums correctly and implement the
checks for switch cases.
We were hoping to use these to allow for plus_zero to be easily reverted. It
turns out that it took more tooling/time than we inticipated, so I am going back
to the old way of doing things. So remove the dead tests.
rdar://34222540
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
This was obscured due to local workarounds. Because the reference is
cross-module, and the symbol itself will be rebased, it cannot serve as
a constant initializer (the value is not known until runtime). However,
using a function pointer is permissible. The linker will materialize a
thunk for the function itself and cause the module to be force linked.
This also works on ELF and MachO as well. The overhead associated with
this is pretty minimal as the function itself has an empty body, and
flags will differentiate between a function and data symbol. The slight
penalty in size (on the order of 2-4 bytes) allows for the same pattern
to be used across all the targets.
We can encounter these when the compiler modifies an inlinable
function to break apart a struct and the struct uses a private
type for one of its fields. It's questionable whether we /should/
handle this, but meanwhile this /is/ a non-intrusive fix that
preserves the performance of non-resilient libraries.
(That is, it appears this worked in Swift 4.0, though perhaps
not all of the same optimizations kicked in.)
https://bugs.swift.org/browse/SR-6874
@noescape function types will eventually be trivial. A
convert_escape_to_noescape instruction does not take ownership of its
operand. It is a projection to the trivial value carried by the closure
-- both context and implementation function viewed as a trivial value.
A safe SIL program must ensure that the object that the project value is based
on is live beyond the last use of the trivial value. This will be
achieve by means of making the lifetimes dependent.
For example:
%e = partial_apply [callee_guaranteed] %f(%z) : $@convention(thin) (Builtin.Int64) -> ()
%n = convert_escape_to_noescape %e : $@callee_guaranteed () -> () to $@noescape @callee_guaranteed () -> ()
%n2 = mark_dependence %n : $@noescape @callee_guaranteed () -> () on %e : $@callee_guaranteed () -> ()
%f2 = function_ref @use : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
apply %f2(%n2) : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
release_value %e : $@callee_guaranteed () -> ()
Note: This is not yet actually used.
Part of:
SR-5441
rdar://36116691
Extend witness tables with a pointer to the protocol conformance
descriptor from which the witness table was generated. This will allow
us to determine (for example) whether two witness tables were
generated from the same (or equivalent) conformances in the future, as
well as discover more information about the witness table itself.
Fixes rdar://problem/36287959.
This is technically a source break, but the @_fixed_layout attribute
is not official yet. If anyone really cares, we can make this
conditional on -swift-version 5 later, but I'd rather not.
This change is necessary so that we can give property initializers
non-public linkage. Currently they are public, because they can be
referenced from inlinable initializers.
Now that property initializers inside a @_fixed_layout type can
only reference public symbols, they no longer have to be public,
but making that change requires a bit more work.
This makes them consistent no matter what shenanigans are pulled by
the importer, particularly NS_ENUM vs. NS_OPTIONS and NS_SWIFT_NAME.
The 'NSErrorDomain' API note /nearly/ works with this, but the
synthesized error struct is still mangled as a Swift declaration,
which means it's not rename-stable. See follow-up commits.
The main place where this still falls down is NS_STRING_ENUM: when
this is applied, a typedef is imported as a unique struct, but without
it it's just a typealias for the underlying type. There's also still a
problem with synthesized conformances, which have a module mangled
into the witness table symbol even though that symbol is linkonce_odr.
rdar://problem/31616162
* rename "Name" to "Description" in the pass definition, because it's not really the pass name, but the description of a pass
* remove the getName() from Transforms (which actually returned the description of a pass)
* in debug printing, print the pass ID and not the pass description. It makes it easier to correlate the debug output to the actual pass implementation.
* remove the iteration numbering in the pass manager, because we only run a single iteration anyway.
Follow-up to ac6fd7214 that adds a similar feature for enums. This
probably doesn't come up much, but the infrastructure's already there.
(The previous commit showed that the other places we do recovery
already handle this from their normal collection of "dependency
types".)
