Now that we enforce the restriction that they can only reference public
symbols, we can allow the optimizer to fully inline them away in client
code.
This is the second part of <rdar://problem/36454839>.
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.
We don't use them from outside the module, because we want to
resiliently change a stored property to computed and vice versa.
Fixes <rdar://problem/32937029>.
In a situation where normal arguments are +0, we want setters to still take
normal parameters at +1 since in most cases setters will be taking a parameter
that is being forwarded into to be store into a field.
Since this doesn't actually change the current ParameterConvention for setter
normal arguments, this is NFC.
rdar://34222540
* [runtime] Clean up symbols in error machinery.
* [runtime] Clean up symbols in Foundation overlay.
* [runtime] Clean up symbols in collections and hashing.
* [runtime] Remove symbol controls from the Linux definition of swift_allocError.
* [tests] Add more stub functions for tests that link directly to the runtime.
Some changes I was working on uncovered a latent bug where we would
emit a class_method instruction to call an allocating initializer
that did not have a vtable entry.
Previously this wasn't caught because the only example of this in
our test suite was in test/SILGen/objc_bridging_any.swift, which
did not test with IRGen; if it did, an IRGen crash would have been
observed.
Factor out some code duplication to prevent this from happening
again, and add a SILGen test that we emit a vtable entry in this
case, and that the test case passes IRGen also.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
Always give stored property initializers the linkage of the type
that contains them, even if the property is less visible than the
type.
This fixes the case where a type defines a private property, and an
extension in a different file from the same module defines a
constructor.
Fixes <rdar://problem/32743703>.
Use 'hasAssociatedValues' instead of computing and discarding the
interface type of an enum element decl. This change has specifically not
been made in conditions that use the presence or absence of the
interface type, only conditions that depend on the presence or absence
of associated values in the enum element decl.
All we need to store is whether the SILDeclRef directly
references the declaration, or if it references a curry
thunk, and we already have an isCurried bit for that.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This fixes a crash when referencing partially-applied methods
from @_inlineable functions.
Also, curry thunks for private methods do not need shared
linkage; private is sufficient.
Also, add a third [serializable] state for functions whose bodies we
*can* serialize, but only do so if they're referenced from another
serialized function.
This will be used for bodies synthesized for imported definitions,
such as init(rawValue:), etc, and various thunks, but for now this
change is NFC.
This replaces SILDeclRef::getBaseOverriddenVTableEntry(). It lives
in the TypeConverter because it needs to use type lowering information
to determine if the method requires a new vtable entry or not.
Simply mangling the derived method is no longer sufficient. Now also
mangle the base method, so that eventually we handle this sort of
scenario:
class Base {
// introduces: Base.method
func method(_: Int, _: Int) {}
}
class First : Base {
// overrides: Base.method
// introduces: First.method
override func method(_: Int?, _: Int) {}
}
class Second : First {
// overrides: Base.method, First.method
// introduces: Second.method
override func method(_: Int?, _: Int?) {}
}
Here, the override of Base.method by Second.method and the
override of First.method by Second.method require distinct
manglings even though the derived method (Second.method) is
the same in both cases.
Note that while the new mangling is longer, vtable thunks are
always emitted with private linkage, so with the exception of
the standard library which is built with -sil-serialize-all
they will not affect the size of dylibs.
The standard library itself has very few classes so it doesn't
matter there either.
This patch doesn't actually add any support to introduce new
vtable entries for methods that override; this is coming up
next.
This changes the order in which declarations are emitted.
It also means we no longer emit a vtable entry for the
materializeForSet of dynamic storage. Neither of these are
intended to have any functional effect.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
Storing this separately is unnecessary since we already
serialize the enum element's interface type. Also, this
eliminates one of the few remaining cases where we serialize
archetypes during AST serialization.
This allows inlineble initializers to be defined on types that
have stored property initializers.
This is not the final behavior we want; in Swift 4 mode, we want
to give these shared linkage and make them fragile, and enforce
that stored property initializer expressions only reference other
public and versioned symbols.
This will match the behavior of default argument expressions in
Swift 4 mode, and I'll implement it when I do those.
