getInterfaceSelfType gets the interface type of a 'self' parameter outside of the context, like getSelfTypeInContext does for the in-context self type.
getDeclaredInterfaceType gives the declared interface type of a TypeDecl.
getGenericSignatureOfContext returns the dependent generic signature of a decl context.
Swift SVN r10973
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
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
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
innermost DeclContext of the decl that uses the archetype instead of the
actual generic context of the archetype.
<rdar://problem/15453889> Qualified archetypes mangle wrong DeclCtx
Swift SVN r10470
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
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
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
During type checking, fake up a "forwarding" substitution set for constructor decls that maps archetypes to themselves. This is goofy, but type-checking is the place that knows how to make ProtocolConformances, and I don't want to reinvent that. Use these forwarding substitutions in SILGen when emitting a generic allocating constructor so we can properly emit a call to the corresponding initializing constructor.
Swift SVN r4684
LLVM r179073 fixed PointerIntPair to work with an enum class as the IntType member, so we can kill some boilerplate in a few type implementations that were explicitly casting to unsigned to work around PointerIntPair's limitations.
Swift SVN r4652
At the top level, if 'operator' is followed by 'infix', 'prefix', or 'postfix', consider it a contextual keyword, and parse an operator decl following it that looks like:
operator {infix|postfix|prefix} <+> {
attributes…
}
Prefix and postfix operator decls currently admit no attributes. Infix operators have 'associativity {left|right|none}' and 'precedence <int>' attributes.
This patch implements parsing for operator declarations but does not yet attach the declared attributes to func decls for the operators.
Swift SVN r4596
We use three tag bits on Expr*, Stmt*, Decl*, TypeBase* and SILTypeInfo*, and four on DeclContext*, so set the alignment of the pointed-to types formally with alignas(N) instead of relying on operator new passing down the right alignment to the allocator. Get rid of the informal T::Alignment members of these classes and pass alignof(T) to their allocators. Fix the 'operator new' of DeclContext subclasses so that we can actually use the four tag bits PointerLikeTypeTraits<DeclContext*> claims are available.
Swift SVN r4587
A Swift method in an extension cannot override a method nor can it be
overridden by a method. Diagnose this. We may remove this limitation
at a later time.
An [objc] method in an extension can override and can be overridden, so
specifically allow this case. It's useful in our Foundation bindings.
Swift SVN r4308
From a user's perspective, one imports Clang modules using the normal
Swift syntax for module imports, e.g.,
import Cocoa
However, to enable importing Clang modules, one needs to point Swift
at a particular SDK with the -sdk= argument, e.g.,
swift -sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9M.sdk
and, of course, that SDK needs to provide support for modules.
There are a number of moving parts here. The major pieces are:
CMake support for linking Clang into Swift: CMake users will now need
to set the SWIFT_PATH_TO_CLANG_SOURCE and SWIFT_PATH_TO_CLANG_BUILD
to the locations of the Clang source tree (which defaults to
tools/clang under your LLVM source tree) and the Clang build tree.
Makefile support for linking Clang into Swift: Makefile users will
need to have Clang located in tools/clang and Swift located in
tools/swift, and builds should just work.
Module loader abstraction: similar to Clang's module loader,
a module loader is responsible for resolving a module name to an
actual module, loading that module in the process. It will also be
responsible for performing name lookup into that module.
Clang importer: the only implementation of the module loader
abstraction, the importer creates a Clang compiler instance capable of
building and loading Clang modules. The approach we take here is to
parse a dummy .m file in Objective-C ARC mode with modules enabled,
but never tear down that compilation unit. Then, when we get a request
to import a Clang module, we turn that into a module-load request to
Clang's module loader, which will build an appropriate module
on-the-fly or used a cached module file.
Note that name lookup into Clang modules is not yet
implemented. That's the next major step.
Swift SVN r3199
a reliable way to track whether a particular type has been
validated. Instead, add some bits to the type to indicate which stage
of checking it has received. I hate it, but it works and I don't know
of a better way to ensure that types get validated. This subsystem
will need to get rearchitected at some point (ugh).
Reduce the number of places where we build new BoundGenericTypes,
since they need to be validated fully to get substitutions, and then
introduces a number of validateTypeSimple() calls to validate types in
places where we know the validation will succeed, but we need that
information regardless.
Swift SVN r2681
member of a oneof/struct/class/extension to support types nested
within generic classes, e.g., Vector<Int>.ElementRange.
Most importantly, nominal types are no longer inherently canonical. A
nominal type refers to both a particular nominal type declaration as
well as its parent, which may be non-canonical and will vary. For
example, the variance in the parent makes Vector<Int>.ElementRange and
Vector<Float>.ElementRange different types.
Introduce deduction and substitution for nominal types. Deduction is
particular interesting because we actually do allow deduction of T
when comparing X<T>.Inner and X<Int>.Inner, because (unlike C++) there
is no specialization to thwart us.
Swift SVN r2507
polymorphic type when that type is nested within a generic type. The
type-checker still isn't ready to use these declarations in a sane way.
Swift SVN r2501
protocol Document { var title : String }
protocol Versioning { func bumpVersion() }
protocol VersionedDocument : Document, Versioning { }
This commit covers the basic functionality of protocol inheritance, including:
- Parsing & AST representation
- Conforming to a protocol also requires conforming to its inherited
protocols
- Member lookup into a protocol also looks into its inherited
protocols (results are aggregated; there is no name hiding)
- Teach ErasureExpr to maintain lvalueness, so we don't end up
performing a silly load/erase/materialize dance when accessing
members from an inherited protocol.
Swift SVN r1804
