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.
Formal types are defined by the language's type system. SIL types are
lowered. They are no longer part of that type system.
The important distinction here is between the SIL storage type and the SIL value
type. To make this distinction clear, I refer to the SILFunctionTypes "formal"
conventions. These conventions dictate the SIL storage type but *not* the SIL
value type. I call them "formal" conventions because they are an immutable
characteristic of the function's type and made explicit via qualifiers on the
function type's parameters and results. This is in contrast to to SIL
conventions which depend on the SIL stage, and in the short term whether the
opaque values flag is enabled.
Separate formal lowered types from SIL types.
The SIL type of an argument will depend on the SIL module's conventions.
The module conventions are determined by the SIL stage and LangOpts.
Almost NFC, but specialized manglings are broken incidentally as a result of
fixes to the way passes handle book-keeping of aruments. The mangler is fixed in
the subsequent commit.
Otherwise, NFC is intended, but quite possible do to rewriting the logic in many
places.
and ensure that the DeclContext of the SILFunction is used when
mangling substituted archetypes found in inlined variable declarations
that have been reparented into the caller
<rdar://problem/28859432>
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
DIGlobalVariable had the associated expression separated into a
DIGlobalVariableExpression which ties the DIGlobalVariable and the
DIExpression together.
The original implementation of DW_OP_bit_piece was using the wrong base for the
offset. To accommodate a fix for that, the old operation was renamed. Use the
new migration name.
(cherry picked from commit 100eaf889e)
- TypeAliasDecl::getAliasType() is gone. Now, getDeclaredInterfaceType()
always returns the NameAliasType.
- NameAliasTypes now always desugar to the underlying type as an
interface type.
- The NameAliasType of a generic type alias no longer desugars to an
UnboundGenericType; call TypeAliasDecl::getUnboundGenericType() if you
want that.
- The "lazy mapTypeOutOfContext()" hack for deserialized TypeAliasDecls
is gone.
- The process of constructing a synthesized TypeAliasDecl is much simpler
now; instead of calling computeType(), setInterfaceType() and then
setting the recursive properties in the right order, just call
setUnderlyingType(), passing it either an interface type or a
contextual type.
In particular, many places weren't setting the recursive properties,
such as the ClangImporter and deserialization. This meant that queries
such as hasArchetype() or hasTypeParameter() would return incorrect
results on NameAliasTypes, which caused various subtle problems.
- Finally, add some more tests for generic typealiases, most of which
fail because they're still pretty broken.
The original implementation of DW_OP_bit_piece was using the wrong base for the
offset. To accommodate a fix for that, the old operation was renamed. Use the
new migration name.
A pointless use of polymorphism -- the result values are not
interchangeable in any practical sense:
- For GenericTypeParamDecls, this returned getDeclaredInterfaceType(),
which is an interface type.
- For AssociatedTypeDecls, this returned the sugared AssociatedTypeType,
which desugars to an archetype.
- For TypeAliasDecls, this returned TypeAliasDecl::getAliasType(),
which desugars to a type containing archetypes.
- For NominalTypeDecls, this returned NominalTypeDecl::getDeclaredType(),
which is the unbound generic type, a special case used for inferring
generic arguments when they're not written in source.
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
This works around a compiler crash when a top-level closure is inlined
into a different compile unit. The top-level-code function is only
generated once so the parent cannot be resolved in any other CU.
This change is NFC as far as the generated DWARF is concerned.
Fixes SR-2725.
The Darwin linker won't process the debug info if the source file name
is invalid so there is no point in having a fallback implemented there.
<rdar://problem/25130236>
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
