Commit Graph

9 Commits

Author SHA1 Message Date
Pavel Yaskevich
7ed3d754b5 [Serialization] Allow unbound generic types to cross-reference typealias decls
Ideally `UnboundGenericType` should never be serialized but it is
currently allowed to make generic `typealias` declarations without
specifying generic parameters, so it should be allowed to cross
reference typealias decls in such types as well because `NameAliasType`
can't be used until generic parameters are resolved.

This is only a temporary fix and more comprehensive solution is still
pending here, most likely such declarations should not produce
`UnboundGenericType` but instead should copy generic parameters from
underlying type and produce proper `NameAliasType`.

Resolves: rdar://problem/37384120
2018-05-22 18:17:21 -07:00
Doug Gregor
80eae200b6 [AST] Preserve type sugar for generic typealiases
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.

At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
2018-03-21 23:49:17 -07:00
Jordan Rose
13c950d7c2 [Serialization] Handle UnboundGenericTypes of generic typealiases.
Simple latent asserts-only bug. Thanks to Slava for the test case.
2017-04-21 09:31:05 -07:00
Jordan Rose
3639343c53 [Serialization] Distinguish between protocol/extension for types too. (#7794)
Replace an existing flag for cross-references to member types (that
wasn't getting much use) with one consistent with how we lookup
values. This fixes the case where someone actually has a useful type
as a member of a protocol extension, and that type gets referenced in
another module; Dispatch does exactly this.

Because you can currently only define typealiases in protocol
extensions, not new types, there's always a workaround for someone
hitting this issue: just use the underlying type.

https://bugs.swift.org/browse/SR-4076
2017-02-28 10:36:46 -08:00
Jordan Rose
ac90133b8c Update tests for accessibility modifiers becoming context-sensitive keywords.
Swift SVN r19673
2014-07-08 02:17:49 +00:00
Jordan Rose
5557c3972b Update tests for accessibility.
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
2014-06-30 18:50:40 +00:00
Doug Gregor
e064416c8f Update the rest of the testsuite for the array syntax change.
Swift SVN r19223
2014-06-26 05:39:25 +00:00
Ted Kremenek
fad874708e Adjust test cases.
Swift SVN r17964
2014-05-12 22:01:52 +00:00
Jordan Rose
965035dc2a [serialization] Load the decl and type offset arrays from the module.
...but don't do anything with them yet. This does check that they're being
correctly serialized, though.

This introduces a new ADT, PointerIntUnion, which like PointerUnion is an
efficient variant type using the lowest bit of data as a discriminator.
By default, the union can store any pointer-bits-minus-one-sized integer,
but both the integer type and the underlying storage type can be
customized.

Swift SVN r5321
2013-05-25 01:34:52 +00:00