This significantly reduces the amount of overhead incurred when naively importing large external modules without referencing many of its members, which should directly improve response times in the playground. For example, the repro code attached to rdar://problem/16387393 imports Foundation but references none of its members, and with these changes its total compilation time is almost 2.5x faster.
Swift SVN r15479
When importing an Objective-C class, import all of the initializers in
all of its superclasses. When we have no information about designated
initializers for a class, the initializers come in as subobject
initializers. When we do have information about designated
initializers, we (1) use it to sort out subobject from complete object
initializers in that class, and (2) assume that all initializers from
superclasses are complete object initializers. Overall, this better
matches Objective-C's semantics.
Swift SVN r14841
When a subclass does not implement a designated initializer of its
superclass, introduce a stub initializer that simply traps. Such stubs
cannot be invoked directly using Swift syntax, but can be invoked
through the Objective-C runtime and from Objective-C code. Catch such
errors rather than allowing them to violate the memory safety of the
language.
Note that we're currently using cond_fail to trap; this will be
improved in the future,
Swift SVN r14839
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
the DynamicLookupExpr expression and the DeclVisibilityKind::DynamicLookup
enum. These seem right to me, more descriptive than renaming them AnyObject.
With this, I consider 13327098 to be done.
Swift SVN r14654
Make Objective-C initializers inherited according to the inheritance
rules we've specified. Prevent the Clang importer from manually
copying all of the initializers from every superclass into each
class.
This eliminates a ton of extra allocating constructors generated when
importing Objective-C init methods. Now we only generate allocating
constructors for the init methods that are actually declared.
Note that initializer inheritance only actually works for
Objective-C-defined classes. More to come.
Swift SVN r14563
Teach name lookup to find complete object initializers in its
superclass when the current class overrides all of the subobject
initializers of its direct superclass.
Clean up the implicit declaration of constructors, so we don't rely on
callers in the type checker doing the right thing.
When we refer to a constructor within the type checker, always use the
type through which the constructor was found as the result of
construction, so that we can type-check uses of inherited complete
object initializers. Fixed a problem with the creation of
OpenExistentialExprs when the base object is a metatype.
The changes to the code completion tests are an improvement: we're
generating ExprSpecific completion results when referring to the
superclass initializer with the same signature as the initializer
we're in after "super.".
Swift SVN r14551
- Respond to Doug's code review feedback
- Stop hacking around with scopes and use "emplace" to work around RAII in the inactive config case
- Limit use of StringRef on the front-end, in favor of std::string
- Use ArrayRef rather than SmallVector within IfConfigDecl
- Reorder new property declarations on BraceStmt to prevent unnecessary alignment issues
- Update ParseBraceItems to better capture top-level declarations, rather than using token lookahead
Swift SVN r14306
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
This is needed for the implicit conformances we synthesize. Remove a
hack from TypeCheckConstraints to find swift.~= now that it's available
using normal lookup.
<rdar://problem/15410928>
Swift SVN r13850
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
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
