Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
When we type check the signature of a method, determine which method
it overrides (if any) at that time. This ensures that we always have
this information for name lookup (per <rdar://problem/15932845>).
As part of this, start to make the overriding rules a little more
sane. John has worked out more of the model here, but this patch:
- Considers an Objective-C method an override of another Objective-C
method if the selectors match and the type vs. instance-ness of the
methods match. The method types are checked for consistency
(subtyping is okay).
- Diagnoses when a method overrides more than one method from a
superclass, and
- Eliminates the "cannot overload method from a superclass"
diagnostic, which is overly pedantic and oddly limiting.
Note that we lose some amount of checking here. Specifically, we don't
have a good place to check that one has not provided two different
methods that override the same superclass method. The older code did
that (somewhat), and it's not a trivial problem to solve efficiently.
This fixes the part of <rdar://problem/15597226> that is needed for
<rdar://problem/15932845>. It still doesn't handle properties,
subscripts, and undoubtedly other issues.
Swift SVN r13108
This still isn't /that/ lazy because a lot of things can force member
deserialization (such as the type-checker generating a DestructorDecl for
every imported class), and we don't do this in a member-granular way just
yet. I don't see any change in testing time, for example.
But besides just being a good thing in general, this perturbs the order
of imported decls enough to fix <rdar://problem/15799697>: we can now
reliably see that there is a -URL:something: function on NSObject that
blocks any properties named 'URL' from being imported as properties.
(Which we don't actually want; see <rdar://problem/15456130>.)
Swift SVN r12685
Change Pattern::getBoundName to look through VarPatterns,
which means that the presence of var/let in an argument list no longer
change the mangling of the function.
Swift SVN r11780
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
location of variables at SIL generation time.
This patch introduces a SILDebuggerClient that
knows how to resolve the locations of variables
that are generated by the debugger. These
variables have a flag on them that only LLDB
sets.
Swift SVN r11230
NominalTypeDecls and ExtensionDecls have a list of members. Rather than
eagerly populating that list when the nominal or extension is just referenced,
just include a pointer back to the ModuleFile, so that they can be
deserialized when we actually look into the decl. The design here is
general enough that we could do something similar with imported Clang decls.
Clang is even more lazy here: the on-disk representation is a hash table,
so lookup only forces deserialization of members with the same name. We
probably want that some day, but this might be enough to get by for now.
This is groundwork for loading partial ASTs, where eagerly deserializing
members leads to circular references we're not able to handle.
Swift SVN r11219
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
Qualified lookup depends not only on the current module but actually the
current file, since imports are file-scoped by default. Currently this only
affects lookup into other modules (e.g. "Foundation.NSString"), but this
could also be used for extension filtering.
This breaks one name resolution test, but the refactoring in the next
commit changes everything anyway and will restore the test.
Swift SVN r10831
This addresses the bulk of <rdar://problem/15344950>, which involes us
not being able to find local variable declarations in expressions when
the parser didn't pre-bind them for us.
The fix to name lookup itself insures that a case such as
case (var a, a)
doesn't allow the second 'a' to find the first.
Swift SVN r9858
And, properly treat imports as per-file: when looking up decls through the
TU module, don't pick up every other source file's imports.
This implements our resolution rules:
1. Check the current source file.
2. Check the current module.
3. Check imported modules.
Currently, "import Foo" is treated as a file-private import and
"@reexported import Foo" is treated as a public /and/ module-wide import.
This further suggests that access control is the right tool for re-export
control:
(private) import Foo // current file only
package import Foo // whole module
public import Foo // whole world
Swift SVN r9682
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
UnqualifiedLookup to ask an external source for
names. There are two phases to this external lookup:
- Before consulting globals in other modules,
UnqualifiedLookup calls lookupOverrides() to see
if there are any results that should override the
results from modules. (N.b.: these should not be
able to override names that are locally defined.)
- After consulting globals in other modules,
UnqualifiedLookup as a last resort calls
lookupFallbacks() to see if there's anything out
there at all that could serve that name. This may
be more computationally expensive.
These hooks are used by LLDB's expression parser to
resolve names for persistent variables (akin to the
existing $0, $1, ... variables) and variables local
to the current frame.
Swift SVN r9014
Instead of relying on the subpattern being a well-formed TuplePattern, let's track our own subelements so we can associate them to properties and validate them ourselves.
Swift SVN r8771
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
Clean up the "can be accessed by dynamic lookup" predicate so that it
checks for a generic context. We no longer need to do the checking in
name lookup, since this means that the dynamic lookup table won't have
anything we can't use (thanks Jordan!). Drop the [objc] allowance for
members of a generic context: it still leaves us with a very weird
case of messaging something when we can't even figure out the type
that we think the object has.
Extend the walk searching for members to include inner classes within
structs, so we get all of the members globally.
Swift SVN r7799
Previously, export control (via [exported]) only applied to modules that
had been serialized -- anything imported in a TranslationUnit was
automatically considered exported. This was done to make life easier when
dealing with the main source file, but it turns out we're going to want to
load other source files as imports, and export control should work there too.
Now, the module iteration methods (Module::forAllVisibleModules,
namelookup::lookupInModule, etc.) can consider the module being passed as
"top-level", meaning its private imports are visible as well. Otherwise,
proper export control is observed even for imported TranslationUnits.
This required a number of test changes involving Swift adapter modules that
forgot to re-export their Clang modules.
Swift SVN r7783
If we allowed dynamic lookup to find a member of a generic class, we
would then have to figure out the generic arguments. Technically, it's
possible that we could deduce the generic arguments from the signature
of the function we found... but it feels unlikely that we'd get the
right answer often enough to make it useful. So don't do that.
Swift SVN r7758
Unlike normal overload resolution, where we always want the
most-specialized, overriding result, overload resolution for dynamic
lookups favors results in superclasses to those in subclasses, because
we want to put the least requirements on the object
type. Additionally, we don't allow overload resolution to select among
results that come from different classes or protocols.
Swift SVN r7743
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
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
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
...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
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
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
