These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
This doesn't handle cross-references to decls /loaded/ from the header
just yet, so all that's testable right now is whether the header's imports
are visible from the secondary target (after being imported in response
to loading the serialized module).
More of <rdar://problem/16702101>
Swift SVN r17638
Previously, cross-references just carried a chain of identifiers and a
top-level module, plus a type to validate against, a generic parameter index,
or an operator fixity. However, referencing "the first generic parameter
of the prefix function ++ that takes a ForwardIndex" requires /all three/
of these filters to unambiguously select the right declaration.
Now, cross-references consist of a chain of trailing records, one for each
link in the path. There are (currently) five kinds of links:
Type: a declaration that cannot have overloads
Value: a declaration that can have overloads (filtered by type)
Extension: filter to decls within extensions on another module
Operator:
- as the first path piece, an operator declaration
- as a later path piece, a fixity filter for operator functions
Generic Param: an indexed generic parameter of the previous result
This should allow us to uniquely cross-reference any Swift declaration we
need to.
Swift SVN r11399
SerializedSILLoader to hold a list of SIL deserializers.
Also add an intial implementation of a linking pass that is run right after
SILGen to link the declaration of SILFunction to the actual definition in
the serialized module.
We add two blocks to the serialized module: a sil index block that
maps identifier to a function ID and also holds a list of function offsets,
and a sil block for the actual SILFunctions. We can probably use subblock
instead of two top-level blocks.
The serialization/de-serialization of the function hash table and the function
offsets are implemented. But we are missing handling of types (see FIXME in
the code).
ModuleFile::Serialized is made public to be used by SIL deserializer, as well
as ModuleFile::getType.
The SIL deserializer holds a pointer to the ModuleFile, it gets the sil cursor
and the sil index cursor from the ModuleFile. The other option is for SIL
deserializer to find the start of the two sil blocks within itself, thus having
less coupling with ModuleFile.
No testing case yet because we are missing handling of types.
Swift SVN r8206
This separates the concerns of "deserialization the AST structures" from
"reading and accessing a module file".
No functionality change.
Swift SVN r7338
Like Clang, ModuleFile contains state about reading the serialized module,
while SerializedModuleLoader takes the place of ASTReader in tracking
cross-module data. I'm diverging from Clang's architecture a bit here by
pushing the actual deserialization logic into ModuleFile.
No functionality change.
Swift SVN r5174
