Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
Constructors and methods had two parameter lists, one for self and one
for the formal parameters. Destructors only had one parameter list,
which introduced an annoying corner case.
The "subclass scope" is meant to represent a connection to a vtable (and how
public something needs to be), for things that end up in class
vtables. Specializations and thunks are mostly internal implementation details
and do not end up there, so subclass scope is not applicable to them. This stops
the thunks and specializations being incorrectly public.
(Note, there are some thunks that _are_ public facing: if a function has its
signature optimized, the original entry point becomes a thunk, and this entry
point is what ends up in vtables etc., so needs to remain around, which means
keeping the same hacks for `private` members of an `open` class.)
Fixes rdar://problem/40738913.
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
Because of a ill-advised core team decision, Swift now
allows @_inlineable root initializers on types that
are not @_fixed_layout (aa85e4512f).
Since stored property initializers of types that are not
@_fixed_layout are permitted to reference non-public symbols,
they cannot be serialized and must instead have public
linkage. This negates most of the benefit of inlining the
constructor in the first place, but oh well.
This does not affect resilient builds.
Fixes <rdar://problem/38439363>.
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.
