The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
Some AST nodes and SIL instructions need to reference conformances for a
particular type. If that type was imported from Clang, however, the
conformance may not exist when the AST node or SIL function gets deserialized
later. The SIL case is the problem case: fragile SIL code may contain a
reference to a conformance never mentioned in the AST of the code being
compiled, and since conformances are synthesized on demand during type-checking,
this will lead to a crash. SIL deserialization isn't supposed to be doing
work on its own (though it ~can~ import new Clang decls at the moment), so
the best answer is to serialize the conformances directly, like we would with
specialized or inherited conformances.
We can probably do better here in the long run (we don't even unique
conformances like this within a module), but this should at least handle the
immediately known problem cases.
rdar://problem/18669402
Swift SVN r22857
SIL functions use AST GenericParamTypeDecls, but they don't have a useful
DeclContext, so they just use the AST module associated with the current
SILModule. However, when it comes time to reserialize referenced functions
with shared_external linkage (such as closures defined in fragile public
functions), the serializer was trying to cross-reference those generic
parameters rather than reserialize them, because they aren't part of the
current source file. And because these decls aren't attached to a specific
AST DeclContext, we can't properly cross-reference them---nor should we.
This commit introduces a targeted case in the cross-reference logic to force
re-serializing these declarations. In the long run we may want to reconsider
using AST GenericParamLists for SILFunctions.
rdar://problem/18673024
Swift SVN r22800
This is needed for tests which define internal functions which should not be eliminated.
So far this was not needed because of a hack which prevented whole-module-optimizations for tests.
Swift SVN r22658
generates them.
Modify getAsCanonicalGenericSignature to dump same-type requirements last.
Also mix the conformance requirements on assocaited archetypes with the witness
markers.
SILParser used to put witness markers for all assocaited archetypes, then
add same-type requirements, and finally the conformance requirements on
associated archetypes. This causes mismatch types between deserialized
SILFunctionTypes and parsed SILFunctionTypes.
rdar://17998988
Swift SVN r21423
The second type of WitnessMarker for deserialized GenericSignature is null.
But the second type for parsed GenericSignature is not null, causing type
mismatch error when linking a SILFunction.
This commit ignores the second type of WitnessMarker when profiling the
GenericSignature.
rdar://17998988
Swift SVN r21178
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
Entities with shared linkage are allowed to be discarded if they are unused even
in a library context.
Previously we implemented this in the serializer, which introduced
needless complications. Now we leave that responsibility to the optimizer giving
simplicity.
Swift SVN r16150
