In Swift, a module is expected to know which libraries it needs, rather than
having this specified by an external module map. While we haven't quite
designed this yet (frameworks get this for free in Clang, for example),
we can at least provide a simple option for the common case of a module
associated with a single library.
This will probably change in the future, so I left in the more general
deserialization code I was working on before simplifying the use case.
A loaded module can in theory specify any arbitrary frameworks or libraries
as dependencies, not just a single dylib.
Swift SVN r7583
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).
Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.
Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.
Swift SVN r7462
Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
proposal.
When compiling with debug info, build a swiftmodule that contains all the
type decls referenced by DWARF and emit it into a special __apple_swiftast
section in the .o file.
Swift SVN r7398
Make the functions support a wider range of builtins and store types to make
it possible.
This is an optimization - the cached ID will be used for builtin identification,
instead of retrieval of the string name and using it as the key.
Swift SVN r7390
Another baby step toward a proper canonical form for polymorphic
function types: generic parameters will eventually be uniquable by
their depth and index.
Swift SVN r7380
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
This separates the concerns of "deserialization the AST structures" from
"reading and accessing a module file".
No functionality change.
Swift SVN r7338
This will be used to resolve properties and method calls on objects with
dynamic-lookup ("id") type. For now, this is tested in swift-ide-test
by using the -dynamic-lookup-completion option and providing a
-code-completion-token value.
Caveats/TODOs:
- As before, since we're using the global method pool, this isn't scoped by
module. We could do a per-module filter, but I don't know if that will
actually buy us much.
- Again, Clang's method pool does not include methods from protocols.
- Lookup by selector name cannot find properties with a customized getter
name. <rdar://problem/14776565>
- The Clang-side method pool is keyed by selector, but Swift wants to look
things up by method name, which maps to the first selector piece, so we
end up having to do a scan of all the selectors in the pool.
Swift SVN r7330
Break cycles agressively when we find circular class inheritance. The
stronger AST invariants prevent us from having to check for loops
everywhere in the front end.
Swift SVN r7325
First, make it actually check for cycles properly. Second, pull it
into the checking of the protocol itself, rather than keeping it as a
separate pass that happens too late to be useful. Finally, put the
unchecked/checking/checked bits into the AST to avoid having to keep a
separate DenseMap just for this purpose. Fixes <rdar://problem/14750346>.
Swift SVN r7324
With this, we can now get a list of all class members* available in the
current translation unit, which will be necessary for doing id-style
dynamic lookup (inferring which method you're referring to when the base
type is some magic "dynamic lookup" type).
* Including members of protocols, since a class we don't know about could
have implemented the protocol.
Since there is no code currently using this, I've added a new mode to
swift-ide-test to just dump all class members -- what will eventually
happen when you code complete on a dynamic lookup type. This mode will
go away once the other pieces of id-style lookup are in place.
Swift SVN r7287
Deserializing a typealias's underlying type can lead to us trying to
deserialize the alias again. When we get back to the outer request,
check to see if there was an inner request, in which case we don't need
to do anything else.
<rdar://problem/14757837>
Swift SVN r7280
...by adding a new callback to ModuleLoader: loadDeclsConformingTo.
This is used only when the type checker doesn't have enough contextual
information to resolve an expression involving a literal, so it's
possible many *LiteralConvertible types will never be loaded.
Deserialization of types with conversion methods is still eager, since
there's no easy hook to tell when they're needed, but the list has been
renamed to refer to any decls that need to be eagerly deserialized, in
case we need it for other purposes in the future.
This probably won't help much in a real program, but it cuts the test
run time by about 5-10% in my build.
Swift SVN r7268
This is really two commits in one: first, change the AST and TypeChecker
to only track conformances to known protocols, and second, make sure we
can deserialize decls that conform to known protocols on demand. The
latter is necessary for the type checker to solve constraint systems that
are not fully constrained, and also requires tracking decls with conversion
methods.
Currently decls conforming to known protocols are eagerly deserialized;
that will change soon to be a new ModuleLoader callback. Decls with
conversion functions will continue to be eagerly deserialized for the near
future.
This fixes the initial regressions in making decl deserialization lazy.
Swift SVN r7264
This also makes extension-loading slightly more precise; if asked to
load extensions for some struct Foo, we will load extensions for /every/
struct Foo...but now we won't /also/ load extensions for every /class/ Foo.
Swift SVN r7260
This switches from simple lists of decls to name-based on-disk hash tables,
which allows decls to be loaded lazily when doing simple lookup (but not
code completion, at least not yet).
The on-disk hash table implementation is borrowed from Clang; eventually
it will be pushed down to LLVM's Support library. (Fortunately the
implementation is header-only.)
This breaks a few tests that rely on magic protocols like
IntegerLiteralConvertible, because the type checker won't have seen the
types that conform to those protocols yet. This will be fixed by doing
an additional "hey, modules, got any of these?" lookup.
Swift SVN r7259
Every valid source location corresponds to a source buffer. There should be no
cases where we create a source location for a random string. Thus,
findBufferContainingLoc() always succeeds.
Swift SVN r7120
Teach the ArchetypeBuilder how to use callbacks to get at the
protocols from which a protocol inherits and to which an associated
type conforms, so that we can use the type checker's lazy resolution
here.
Swift SVN r7107
- New type representation OptionalTypeRepr.
- New sugared type OptionalType.
- New base type SyntaxSugarType, parent of ArraySliceType and OptionalType.
These two are the same in a lot of ways.
- The form "T[]?" is forbidden, because it makes "Int[4][2]" oddly
different from "Int[4]?[2]". The type can be spelled "(T[])?" or
Optional<T[]>.
- Like Slice, "Optional" is just looked up in the current module. This may
or may not be the desired behavior in the long run.
<rdar://problem/14666783>
Swift SVN r7100
This should complete support for Swift-side export control.
Note that a TU's imports are still all "re-exported" (i.e. returned from
getReexportedModules) whether they are marked [exported] or not. This is
a convenient trick to get lookup in the main source file to look at all
imported modules, but if we allow real multi-TU compilation we'll have to
revisit this.
Swift SVN r7052
Previously, a module contained references to every module listed in the
ASTContext. Now, we actually only encode the imports from the TU itself,
which allows us to include access paths for scoped imports.
This is necessary to implement proper name lookup shadowing rules.
Swift SVN r7013
We can get to these transitively; we should only record what the TU
actually claims to reference.
It turns out that we were still relying on this to force the load of
adapter modules for Clang modules. For now, we just force that up front,
even though currently that also forces the creation of ClangModule
wrappers for all transitive includes.
No intended visible functionality change.
Swift SVN r7012
The current implementation of dealloc_stack in IR-gen is a
no-op, but that's very much wrong for types with non-trivial
local allocation requirements, e.g. archetypes. So we need
to be able to do non-trivial code here. However, that means
modeling both the buffer pointer and the allocated address
in SIL.
To make this more type-safe, introduce a SIL-specific
'[local_storage] T' type that represents the required
allocation for locally storing a T. alloc_stack now returns
one of those in additon to a *T, and dealloc_stack expects
the former.
IR-gen still implements dealloc_stack as a no-op, but
that's now easy to fix.
Swift SVN r6937
Factor the ProtocolConformance class into a small hierarchy of
protocol conformances:
- "normal" conformance, which provides a complete mapping for the
explicit conformance of a nominal type (which may be generic) to a
protocol;
- "specialized" conformance, which specializes a generic
conformance by applying a set of substitutions; and
- "inherited" conformance, which projects the conformance from a
superclass to a conformance for a subclass.
In this scheme "normal" conformances are fairly heavyweight, because
they provide a complete mapping. Normal conformances are unique,
because they're associated with explicit conformance declarations
(which cannot be repeated within a module; checking is TBD). Thus, IR
generation will eventually emit them as strong symbols.
"Specialized" and "inherited" conformances occur when we're dealing
with generic specializations or subclasses. They project most of their
members through to some underlying conformance, eventually landing at
a "normal" conformance. ASTContext is responsible for uniquing these
conformances when it sees them. The IR generation model for
specialized conformances will involve runtime specialization of the
underlying witness table; inherited conformances are probably no-ops
from the IR generation perspective.
Aside from being the right thing to do, having small, uniqued
conformances for the specialization and inheritance cases is good for
compile-time performance and memory usage. We're not really taking
advantage of this everywhere we could, yet.
This change uncovered a few existing issues (one known, one not
known), particularly because we're projecting inherited conformances
rather than building new conformances:
- <rdar://problem/14620454>: protocol witnesses to methods of
classes need to perform dynamic dispatch. See the
test/Interpreter/typeof.swift test for an example.
- <rdar://problem/14637688>: comparing NSString and String with ==
fails, because they are inter-convertible. I suspect we were missing
some protocol conformances previously, and therefore accepting this
obviously-invalid code.
Swift SVN r6865
Note that the import kind is not checked yet; this is effectively our old
behavior for "import swift.print".
Infrastructure: move Module::forAllVisibleModules out-of-line, and add
makeStackLambda to STLExtras for using a non-escaping lambda with
std::function.
Swift SVN r6852
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
This should include all of the attributes we care about for the time being.
Only the resilience attributes (not designed) and [force_inline] are left
unaccounted for.
Swift SVN r6767
When we notice that a type implicitly conforms to a protocol but is
not explicitly stated to do so, note this and provide a Fix-It
attaching the conformance to a declaration within the translation
unit, e.g.,
t.swift:28:16: error: type 'S1' does not explicitly conform to protocol 'P'
var p1 : P = S1()
^
t.swift:8:8: note: introduce explicit conformance to protocol 'P'
struct S1 : Q {
^
, P
Swift SVN r6760
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
Add BCOffsetRAII to getDecl() and getType() so that these functions
preserve the current cursor position. This spends an extra save and
restore to avoid accidentally shooting ourselves in the foot by losing
our position (see r6516).
No functionality change.
Swift SVN r6750
