Fixes two bugs in Clang importer and deserialization code that were found by
the verifier:
(1) FuncExprs were created with a null FuncDecl
(2) BoundGenericType that was created by Clang importer for UnsafePtr<> and
other magic types did not have substitutions.
Swift SVN r8073
The new ConcreteDeclRef class provides a possibly-speciaized reference
to a declaration, which allows DynamicMemberRefExpr to refer to both
generic and non-generic members. without having to split the AST node.
Swift SVN r7839
functions whenever we build a reference to a [weak]
variable in the AST.
We're going to consume this during SIL-gen, so the
assumption here is that we never do SIL-gen of an Expr
that we didn't run through the type-checker.
Swift SVN r7716
We previously relied on the type checker to fill in the implementation
types (swift.Slice<T> and swift.Optional<T>, respectively), which
limited our ability to perform type transformations in the AST. Now,
the AST knows how to form these implementation types on demand.
Swift SVN r7587
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
...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
- 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
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
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
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
Previously, we only tracked the mapping from associated types to their
type witnesses. Now, also track the protocol conformances for each of
the requirements placed on the associated types.
Swift SVN r6655
importing them
Because going through the import for every code completion request is slow,
Clang code completion results are cached in the CodeCompletionContext. The
cache needs to be invalidated whenever a new Clang module is loaded. In order
to implement this, ModuleLoadListener class was added.
Swift SVN r6505
Elements of a tuple type now know if there is a default argument, and
what kind of default argument it is (callee side, __FILE__, __LINE__,
__COLUMN__), but they don't have an actual expression. There are a
number of cleanups this enables that will follow.
Note that the serialization support is as-yet-untested.
Swift SVN r6351
-Refactor Parser to stop creating types
-Refactor TypeChecker to create types by resolving TypeReprs.
-Remove "validation" bit from the type system.
We don't need to "validate" every type that gets created but there's still a validation bit in TypeLoc,
necessary because of generic substitutions.
Swift SVN r6326
Refactored the function calling conventions,"thin" attribute, and other extra function info bits to be stored inside the TypeBits. The isAutoClosure and IsBlock bits are also pulled up into AnyFunctionType.
This should make it easier to construct and propagate the attributes. Using ExtInfo struct to simplify the FunctionType is coming up next.
Swift SVN r6284
Introduces very basic support for diagnosing ambiguous expressions,
where the source of the ambiguity is a reference to an overloaded
name. Simple example:
t.swift:4:1: error: ambiguous use of 'f0'
f0(1, 2)
^
t.swift:1:6: note: found this candidate
func f0(i : Int, d : Double) {}
^
t.swift:2:6: note: found this candidate
func f0(d : Double, i : Int) {}
^
There's a lot of work needed to make this cleaner, but perhaps it will
ease the pain of developing the library <rdar://problem/14277889>.
Swift SVN r6195
The idea for now is that this is a SIL-only type used for
representing the storage of a weak or unowned reference.
Having it be its own type is pretty vital for reasonable
behavior in SIL and IR-generation, and it's likely that
this will surface into runtime metadata as well (hence
the mangling).
I've implemented a bunch of things that technically I don't
think are necessary if this stays out of the typechecker,
but it's easier to implement half-a-dozen "recurse into
the child type" methods now that it would be to find them
all later if we change our minds.
Swift SVN r6091
The lookup table for a nominal type declaration provides efficient
(O(1)) access to all of the declarations with a given name in a
nominal type and its extensions. This is architecturally different
from Clang's handling of Objective-C classes and
categories/extensions, where each category/extension has its own
lookup table, and is meant to reduce the number of hash table lookups
required, especially once these hash tables are stored in the module.
The lookup table is built and updated lazily as extensions and members
are introduced, similarly to Clang's lookup tables. However, the
simpler name lookup rules in Swift (vs. C/C++/Objective-C) make this
approach actually semantically correct.
Swift SVN r5874
This causes the SourceLoader to recursively parse the imported module in standard
library mode, giving it access to the Builtin module.
This is all a terrible hack and should be ripped out with great victory someday, but
until we have binary modules that persist the build setting used to produce the
module, this is the best we can do.
Swift SVN r5847
This adds builtin types Builtin.VecNxT, where N is a natural number
and T is a builtin type, which map down to the LLVM type <N x T>.
Update varous builtins to support vector arguments, e.g., binary
operations, comparisons, negation. Add InsertElement and
ExtractElement builtins for vectors.
On top of these builtins, add Vec4f and Vec4b structs to the standard
library, which provide 4xFloat and 4xBool vectors, respectively, with
basic support for arithmetic. These are mostly straw men, to be burned
down at our leisure.
Some issues as yet unresolved:
- Comparisons of Vec4f'ss are producing bogus Vec4b's, which I
haven't tracked down yet.
- We still don't support the shuffle builtin, although it should be
easy
- More testing!
Swift SVN r5820
guard access to the Builtin module (on one path), reducing the number
of ways non-stdlib and non-sil files have access to the builtin module.
Swift SVN r5767
Keep track of each of the nominal type declarations and extensions
thereof that conform to each protocol. When the type checker runs out
of other ideas for a type variable, enumerate the types known to
conform to the protocols it requires. Fixes <rdar://problem/14014895>
and eliminates the extra casts introduced in r5639.
Swift SVN r5645
This replaces the obscure, inefficient lookup into extensions with
something more straightforward: walk all of the known extensions
(available as a simple list), then eliminate any declarations that
have been shadowed by other declarations. The shadowing rules still
need to consider the module re-export DAG, but we'll leave that for
later.
As part of this, keep track of the last time we loaded extensions for
a given nominal type. If the list of extensions is out-of-date with
respect to the global generation count (which tracks resolved module
imports), ask the modules to load any additional extensions. Only the
Clang module importer can currently load extensions in this manner.
Swift SVN r5223
We decided we're going to want to surface fine-grained representational control of functions to the user, so move AbstractCC and the calling convention attributes into the Swift type system. Like the [thin] attribute, we don't set this in the type-checker or importer at all yet, and let SILGen set the attribute where it wants it for now.
Swift SVN r5222
