If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
Use the just-introduced functionality to track the member types of a
type variable to allow type substitution to look up a member type of a
type variable, rather than failing to substitute. NFC yet.
Swift SVN r12972
This fixes an awful nondeterministic memory smasher involving cases
where the type checker checks whether a type involving type variables
conforms to a given protocol. The checks were cached in an
ASTContext-level data structure, but the keys involved
constraint-checker-allocated types. Stale entries in the cache caused
all manners of unreproducible weirdness, almost surely including
<rdar://problem/15715339>, <rdar://problem/15736793>,
<rdar://problem/15768325>, and probably others.
Swift SVN r12898
We'll need to perform name lookup based on the file-level
DeclContext*, so the module no longer suffices. No functionality
change here yet.
Swift SVN r11523
This is a structural baby step toward lazily filling in protocol
conformances. We always build a ProtocolConformance, then mark it
either "complete" (when it's well-formed) or "invalid" (when it's
ill-formed). At present, the only benefit to this is that it slows
diagnostic cascades from invalid conformances.
Swift SVN r11492
...rather than a raw pointer that points to a buffer with space for N
elements. Just because we *can* get N from context doesn't mean it's
convenient/safe.
No functionality change.
Swift SVN r11488
A SpecializedProtocolConformance intentionally contains all of the
information we need to synthesize the type witnesses from the
underlying (generic) conformance. Do so lazily rather than eagerly,
because we won't always need all of them.
As a nice side effect, we no longer need to serialize the witnesses of
these specialized protocol conformances, so we can save some space in
the Swift module file.
Swift SVN r11303
Also updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to get the ImportSearchPaths from the ASTContext’s SearchPathOpts, instead of directly from the ASTContext.
Swift SVN r11214
Added a new SearchPathOptions class to swiftAST, which will contain options like import search paths and the SDK path.
Moved the RuntimeIncludePath from CompilerInvocation into SearchPathOptions. For now, at least, the RuntimeIncludePath is handled separately from other ImportSearchPaths, since we can’t yet guarantee that RuntimeIncludePath is set up before we parse the ImportSearchPaths.
Added a SearchPathOptions member to ASTContext.
Updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to check RuntimeIncludePath after everything else if no module was found. (This matches existing behavior, which had RuntimeIncludedPath at the end of ImportSearchPaths.)
Swift SVN r11213
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 Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
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
Right now the type checker is responsible for marking known protocols in the
imported AST for 'swift' module. If we don’t run the type checker, known
protocols are not marked correctly.
This patch moves the code to mark known protocols from libSema to libAST and
calls it when we load the standard library module.
Motivation: Swift tools might want to deserialize a module and inspect the AST
(for example, print it). There is no need to invoke the type checker in this
case, and we don’t even have a TU.
Swift SVN r8704
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
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
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
