Apparently, this code was written this way because getCanonicalType() on a
TypeAliasDecl which represented generic parameter used to assert().
Swift SVN r7447
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
And use them to decide if an llvm intrinsic apply instruction can be considered dead.
(This is a hack because it uses LLVM Global context. However, we already use
this approach elsewhere.)
Swift SVN r7404
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
a syntax error. Usually the type parsing can just return nullptr for the
TypeRepr, but when we want to construct an AST node that should have included
that type, we should provide a non-null TypeRepr.
Swift SVN r7375
This is a baby step toward eliminating GenericParamList from
PolymorphicFunctionType, fixing up the easy callers. No functionality
change.
Swift SVN r7370
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
A part of my mind wanted to skip the kind check in Module's implementation
of these if we already knew we were dealing with a LoadedModule, but the
extra level of indirection is fairly annoying. Just jump straight to the
LoadedModule's owner here.
(We can't use virtual methods because we want Module to stay vtable-free.)
Swift SVN r7337
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
...so, add a templated overload that ensures that lambdas aren't copied,
so that callers don't need to add an explicit makeStackLambda().
No functionality change.
Swift SVN r7303
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
Union cases were still being printed enum-style, and computed vars,
subscripts, and typealiases would print their definitions even when
the corresponding printing option was disabled. All fixed.
Swift SVN r7285
...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
ForStmt::Cond is already a NullablePtr<>. This patch changes
ForStmt::Initializer and ForStmt::Increment to be NullablePtr. Otherwise it
looks like Cond can be null, while Initializer and Increment can not.
Swift SVN r7265
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 doesn't do anything yet, but will be used to record which decls
conform to these protocols when serializing a module.
This introduces a new metaprogramming file, KnownProtocols.def.
Swift SVN r7263
Turn NominalType::FieldRange into a more general template that can filter by any member decl type and predicate. Use an instance of it in UnionDecl::getAllElements to iterate through all its contained UnionElementDecls.
Swift SVN r7218
integration
Motivation: libIDE clients should be simple, and they should not have to
translate token-based SourceRanges to character locations.
This also allows us to remove the dependency of DiagnosticConsumer on the
Lexer. Now the DiagnosticEngine translates the diagnostics to CharSourceRanges
and passes character-based ranges to the DiagnosticConsumer.
Swift SVN r7173
This is a tradeoff, assuming that lookup in a particular module is less
likely to be repeated than lookup within the current source file. By
storing the cached results with the TU's own local lookup cache, the
results get cleared out when we parse additional decls.
Since this is only used by code completion, there's no performance benefit
for the compiler, or even for swift-ide-test...it's only in repeated lookups
that this will be useful.
Swift SVN r7169
This makes lookupVisibleDecls use the same code path as qualified and
unqualified lookup. This is more expensive, because it needs to actually
collect a list of /all/ decls in order to properly compute shadowing
information, but this list is not likely to change once the set of imports
has been computed, so we can cache it.
Swift SVN r7168
This should help give a slightly better experience for out-of-order
type checking issues until we manage to make type checking
order-independent. <rdar://problem/14702636>.
Swift SVN r7149
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
- 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 eliminates the pre-pass we were performing to bind the operator
decls, which was only a pre-pass because we used to bind unresolved
declaration references too early. In the process, fixed some bugs
(e.g., it wasn't checking methods at all) and improved the QoI with
Fix-Its and notes:
t.swift:2:6: error: prefix unary operator missing 'prefix' attribute
func ~~~(x : Float) {}
^
[prefix]
t.swift:1:17: note: prefix operator found here
operator prefix ~~~ {}
^
Swift SVN r7099
The only visible change from this now is that diagnostics will come in
a more sensible order, because we do name resolution along with the
rest of type checking, rather than in a separate pass early
on. However, it's foundational for lazy type checking, type
refinement, and various other important features and bug fixes.
Swift SVN r7086
Deduced associated types are implemented by allowing name lookup into
a type to find the requirements in the protocols to which that type
conforms. If the protocol conformance produced the witness for the
requirement via deduction (or, eventually, default definitions), we
use the deduced witness; otherwise, the actual declaration within the
type itself is used.
Previously, the AST-level lookup was deciding whether to filter out
protocol requirements based on the conformance information in the
AST. However, this lead to ordering dependencies, because the type
checker doesn't record the conformances in the AST until we've visited
all of the conformances for a given declaration. This lead to an
oddity where one could have one conformance depend on another's
deduced associated type, but only if that conformance was on a later
extension. Fixes <rdar://problem/14685674>.
As part of this, teach the type checker to re-use normal conformances
that get deserialized, rather than creating new ones. Otherwise, we'll
end up with two different copies of the same conformance running
around.
Swift SVN r7075
As discussed, this is an interim syntax for re-exports:
import [exported] Foundation
In the long run, we're probably going to use the same syntax as access
control for this, but that hasn't been designed yet.
Swift SVN r7050
