Commit Graph

11 Commits

Author SHA1 Message Date
Slava Pestov
8fe8b89b0f SIL: Terminology change: [fragile] => [serialized]
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.
2017-03-29 16:47:28 -07:00
Slava Pestov
efff6a6922 SILGen: Fix a couple of problems with materializeForSet in constrained extensions
- Property defined in constrained extension of a class

- Subscript defined in a constrained extension with non-canonical index type

Fixes <rdar://problem/31222187>.
2017-03-27 00:18:26 -07:00
Erik Eckstein
c4a11f4c92 tests: remove the now unused option -new-mangling-for-tests 2017-03-22 11:28:43 -07:00
Erik Eckstein
a04a29af4f mangling: efficient mangling of repeated substitutions
Instead of appending a character for each substitution, we now prefix the substitution with the repeat count, e.g.
AbbbbB -> A5B

The same is done for known-type substitutions, e.g.
SiSiSi -> S3i

This significantly shrinks mangled names which contain large lists of the same type, like
  func foo(_ x: (Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int))

rdar://problem/30707433
2017-03-05 17:41:43 -08:00
Slava Pestov
0af2845c6d SILGen: Emission of materializeForSet for generic subscripts
First, use the correct generic environment to compute the substituted
storage type. Substitutions derived from 'self' are not enough,
because we also want the archetypes of the generic subscript's
innermost generic parameters.

Also, use the method and witness_method calling conventions for the
materializeForSet callback, depending on if we have a protocol
witness or concrete implementation.

Since the materializeForSet callback is called with a more
abstract type at the call site than the actual function type
of the callback, we used to rely on these two SIL types being
ABI compatible:

@convention(thin) <Self : P, T, U) (..., Self.Type) -> ()
@convention(thin) <T, U> (..., Foo<T, U>.Type) -> ()

The IRGen lowering is roughly the following -- the call site
passes two unused parameters, but that's fine:

(..., Self.Type*, Self.Type*, Self.P*)
(..., Foo<T, U>.Type*)

However if the callback has its own generic parameters because
the subscript is generic, we might have SIL types like so,

@convention(thin) <Self : P, T, U, V) (..., Self.Type) -> ()
@convention(thin) <T, U, V> (..., Foo<T, U>.Type) -> ()

And the IRGen lowering is the following:

(..., Self.Type*, Self.Type*, Self.P*, V.Type*)
(..., Foo<T, U>.Type*, V.Type*)

The parameters no longer line up, because the caller still passes
the two discarded arguments, and type metadata for V cannot be
derived from the Self metadata so must be passed separately.

The witness_method calling convention is designed to solve this
problem; it puts the Self metadata and protocol conformance last,
so if you have these SIL types:

@convention(witness_method) <Self : P, T, U, V) (..., swiftself Self.Type) -> ()
@convention(witness_method) <T, U, V> (..., swiftself Foo<T, U>.Type) -> ()

The IRGen lowering is the following:

(..., Self.Type*, V.Type*, Self.Type*, Self.P*)
(..., Foo<T, U>.Type*, V.Type*, Self.Type*, unused i8*)

However, the problem is now that witness_method and thin functions
are not ABI compatible, because thin functions don't have a
distinguished 'self', which is passed differently in LLVM's swiftcc
calling convention:

@convention(witness_method) <Self : P, T, U, V) (..., Self.Type) -> ()
@convention(thin) <T, U, V> (..., Foo<T, U>.Type) -> ()

So instead of using 'thin' representation for the concrete callback
case, use 'method', which is essentially the same as 'thin' except if
the last parameter is pointer-size, it is passed as the 'self' value.

This makes everything work out.
2017-02-26 21:27:04 -08:00
Slava Pestov
19f54e1e8b SILGen: Clean up materializeForSet emission a bit
We can get the generic signature from the generic environment
now, and for generic subscript protocol witnesses, using the
signature of the conformance is wrong; it won't have the
generic parameters of the subscript itself.

Also, emit the materializeForSet callback in the right place in
SILModule. Instead of adding it at the end, put it before the
materializeForSet itself. This makes tests a bit easier to write.
2017-02-25 15:48:13 -08:00
Slava Pestov
33a8ce6e7b AST: Canonicalize types with respect to generic signature when mangling
In the following example, the two declarations should have
the same mangled type:

protocol P {
  associatedtype P
}

func f1<T : P>(_: T) -> T.P where T.P == Int {}
func f2<T : P>(_: T) -> Int where T.P == Int {}

To ensure this is the case, canonicalize the entire
GenericFunctionType before taking it apart, instead of
canonicalizing structural components of it.
2017-02-20 16:41:37 -08:00
Erik Eckstein
1d3724666f tests: convert about 400 tests to the new mangling by using the -new-mangling-for-tests option
When the new mangling is enabled permanently, the option can be removed from the RUN command lines again.
2017-01-24 15:27:45 -08:00
Slava Pestov
5ab94a6ef0 AST: Add "re-sugaring" to GenericEnvironment
Sugared GenericTypeParamTypes point to GenericTypeParamDecls,
allowing the name of the parameter as written by the user to be
recovered. Canonical GenericTypeParamTypes on the other hand
only store a depth and index, without referencing the original
declaration.

When printing SIL, we wish to output the original generic parameter
names, even though SIL only uses canonical types. Previously,
we used to accomplish this by mapping the generic parameter to an
archetype and printing the name of the archetype. This was not
adequate if multiple generic parameters mapped to the same
archetype, or if a generic parameter was mapped to a concrete type.

The new approach preserves the original sugared types in the
GenericEnvironment, adding a new GenericEnvironment::getSugaredType()
method.

There are also some other assorted simplifications made possible
by this.

Unfortunately this makes GenericEnvironments use a bit more memory,
however I have more improvements coming that will offset the gains,
in addition to making substitution lists smaller also.
2016-10-12 18:56:16 -07:00
Slava Pestov
5893657df5 SILGen: Allow concrete constrained extensions to define constructors
Make sure we go through the common code path for constructors,
like we do for methods and everything else, so that we correctly
drop the generic signature in the case where all generic
parameters were made concrete.

This fixes the example from <rdar://problem/17821143>.
2016-10-11 16:02:54 -07:00
Slava Pestov
8f88d19518 Sema: Allow extensions to make generic parameters concrete via same-type constraints
Fixes <https://bugs.swift.org/browse/SR-1009>.
2016-10-04 20:36:56 -04:00