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
This iterates over a module's exports, transitively, in an unspecified
but deterministic order. This is useful for any sort of lookup and for
managing transitive inclusion. It also allows us to remove the hack in
Sema for loading a Clang module's adapter module, and just rely on the
previous commit.
Swift SVN r6699
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
Rather than automatically re-exporting or not re-exporting every import in
a TranslationUnit, we'll eventually want to control which imports are local
(most of them) and which imports are shared with eventual module loaders.
It's probably not worth implementing this for TranslationUnit, but
LoadedModule can certainly do something here.
Currently, a LoadedModule is even more permissive than a TranslationUnit:
all imports are re-exported. We can lock down on this once we have a
re-export syntax.
Swift SVN r6523
This eliminates the duplicate IdentifierType resolution code (fixing
<rdar://problem/13946567>), and moves us a step closure to elimining
name binding as a separate pass.
Swift SVN r5940
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
wrapping up rdar://11187080
Now the only way you get access to the Builtin module is if you're the standard
library (currently modeled with the -parse-stdlib command line flag, will eventually
be part of build configuration goop or something).
This breaks a few of Jordan's serialization tests, which I've XFAILed after discussion.
Swift SVN r5777
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
library. We use the same (somewhat broken heuristics), they are
just implemented in another way.
The major functionality change is that previously, .sil files would
auto import "swift" if they started with a non-sil decl. Now they
never do.
Swift SVN r5731
Parse '=' as a binary operator with fixed precedence, parsing it into a temporary UnsequencedAssignExpr that gets matched to operands and turned into an AssignExpr during sequence expr folding. This makes '=' behave like library-defined assignment-like binary operators.
This temporarily puts '=' at the wrong precedence relative to 'as' and 'is', until 'as' and 'is' can be integrated into sequence parsing as well.
Swift SVN r5508
1) a DeclContext doesn't need to be passed in, now that IdentifierType tracks it.
2) factor the code that sets Components to ErrorType out of the clients.
Swift SVN r5250
by TranslationUnit. This list existed solely to allow name lookup of
an unbound IdentifierType to know its DeclContext. Instead of indirecting
through this list, just store the DeclContext in the IdentifierType in its
uninitialized state.
This eliminates a really terrible performance fixme about scanning the list,
eliminates the management fiddling around with this list in the parser, and
is generally much cleaner.
Swift SVN r5246
This paves the way for having a Swift module importer. The eventual goal
here is to eliminate all explicit uses of the Clang module loader, but
I'm not going to push too hard on that for now.
Swift SVN r5092
Keep track of external definitions as they are created by broadcasting
them through a mutation listener interface. At name binding time, we
just cache them. When a type checker is alive, it immediately performs
any additional operations necessary on those types (e.g., declaring
implicit constructors).
This also eliminates some O(N^2) behavior in the type checker as well,
because we don't have to walk through all of the module imports to
find the external definitions. We just keep a single list in the
ASTContext along with our place in the list.
Fixes <rdar://problem/13769497>.
Swift SVN r5032
Per Chris's feedback and suggestions on the verbose fix-it API, convert
diagnostics over to using the builder pattern instead of Clang's streaming
pattern (<<) for fix-its and ranges. Ranges are included because
otherwise it's syntactically difficult to add a fix-it after a range.
New syntax:
diagnose(Loc, diag::warn_problem)
.highlight(E->getRange())
.fixItRemove(E->getLHS()->getRange())
.fixItInsert(E->getRHS()->getLoc(), "&")
.fixItReplace(E->getOp()->getRange(), "++");
These builder functions only exist on InFlightDiagnostic; while you can
still modify a plain Diagnostic, you have to do it with plain accessors
and a raw DiagnosticInfo::FixIt.
Swift SVN r4894
This gives us a couple things:
- It lets name binding match up operator funcs to operator decls reliably without depending on unary operators being properly attributed;
- It allows unary operators on tuples to be distinguished from binary operators; the former should always be declared 'func +(_:(x:A,y:B))', and the latter as 'func +(x:A,y:B)'.
Swift SVN r4636
During name binding, associate func decls with operator decls. When parsing SequenceExprs, look up operator decls to determine associativity and precedence of infix operators. Remove the infix_left and infix_left attributes, and make the infix attribute a simple declared attribute [infix] with no precedence.
Operator decls are resolved as follows:
- If an operator is declared in the same module as the use, resolve to the declaration in the current module.
- Otherwise, import operator declarations from all imported modules. If more than one declaration is imported for the operator and they conflict, raise an ambiguity error. If they are equivalent, pick one arbitrarily.
This allows operator declarations within the current module to override imported declarations if desired or to disambiguate conflicting operator declarations.
I've updated the standard library and the tests. stdlib2 and some of the examples still need to be updated.
Swift SVN r4629
Now,
import Cocoa
will bring in the Cocoa Clang module, which re-exports (among
other things), the AppKit, Foundation, and ObjectiveC Clang
modules. We will look for Swift modules of the same name and load them
implicitly.
Swift SVN r4229
Allow an extension to extend a type using a typealias. This allows Clang-imported typedef-ed structs such as NSRect/CGRect to be extended, and in general allows extensions to be used without having to expose users to potentially ugly internal-use-only names like 'Int64'. Fixes <rdar://problem/13280448>.
Swift SVN r4213
We want to make sure that a global lookup always finds the Swift module
first. Moreover, we should never be loading two modules with the same name
into the same TU /unless/ they are (a) identical or (b) a Swift / C pair.
Swift SVN r3723
Swift's diagnostic system is built on the quaint notion that every
declaration known to the front end has a valid source location to
which diagnostics mentioning that declaration (say, in a "here is a
candidate" note) can point. However, with a real module system, the
source corresponding to a declaration in a module does not need to be
present, so we can't rely on source locations.
Instead of source locations, allow diagnostics to be anchored at a
declaration. If that declaration has source-location information, it
is used. Otherwise, we just drop source-location information for
now. In the future, we'll find a better way to render this information
so it feels natural for the programmer.
Swift SVN r3413
This change allows client code to just use, e.g.,
import Foundation
to get both the Clang Foundation module and the Swift Foundation
module that provides various adaptation (typically via
extensions). At some point later, we can consider whether the modules
will end up in different namespaces somehow, or whether this is best
tackled by some kind of module re-export directive, but for now it's
convenient while we await the design of a real module system for
Swift.
Swift SVN r3405
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
the constraint-based type checker:
-constraint-checker turns on constraint-based type checking for the
current swift module (but not imported modules; we're not ready for that)
-debug-constraints turns on detailed debugging information for the
constraint-based type checker
Use these flags to de-REPL-ify the tests for the constraint-based type
checker. The REPL is still quite useful for experimenting with the
type checker, but shouldn't be our normal means of testing it.
Swift SVN r2840
and type validation should never fail in a call to validateTypeSimple.
The one thing I really don't like about this whole approach is that we end
up with validateTypeSimple calls scattered all over the place...
the ultimate solution here is probably something along the lines of
introducing getUnvalidated() getters for types for use from the parser,
and make the standard getters for types assert that the type is valid
and perform any necessary computations themselves.
Swift SVN r2728
and Int[].
Type resolution for types named in ExtensionDecls remains a part of name-binding; it has to use more restrictive rules because we can't perform general member lookup until
we've resolved all the types named in ExtensionDecls.
Swift SVN r2313
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
