Move the rest of associated type inference into the new source file,
and split RequirementEnvironment into its own AST-level header, because it
can be re-used and has no ties to the type checker.
In Clang with r309390 the tablegen headers are all wrapped by a target named clang-tablegen-targets, which is created as an empty target in Clang's CMake configuration. This allows depending on this target directly in both in and out-of-tree builds.
Similarly in LLVM r309389, intrinsics_gen is created in the CMake configuration so that out-of-tree projects can add it as a dependency.
* Generate libSyntax API
This patch removes the hand-rolled libSyntax API and replaces it with an
API that's entirely automatically generated. This means the API is
guaranteed to be internally stylistically and functionally consistent.
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.
SubstitutionList is going to be a more compact representation of
a SubstitutionMap, suitable for inline allocation inside another
object.
For now, it's just a typedef for ArrayRef<Substitution>.
This should help speed up people trying to compile the standard library and do
SILGen work. *NOTE* This will not necessarily result in a type checker that is
as fast as a release build since most likely the type checker will use some
link_once odr functions that are debug. But it should still be significantly
faster otherwise.
This makes getting to SILGen take 16 seconds on my machine instead of forever
when compiling with everything else in the compiler in debug mode.
This reverts the contents of #5778 and replaces it with a far simpler
implementation of condition resolution along with canImport. When
combined with the optimizations in #6279 we get the best of both worlds
with a performance win and a simpler implementation.
Following classes provide symbol mangling for specific purposes:
*) Mangler: the base mangler class, just providing some basic utilities
*) ASTMangler: for mangling AST declarations
*) SpecializationMangler: to be used in the optimizer for mangling specialized function names
*) IRGenMangler: mangling all kind of symbols in IRGen
All those classes are not used yet, so it’s basically a NFC.
Another change is that some demangler node types are added (either because they were missing or the new demangler needs them).
Those new nodes also need to be handled in the old demangler, but this should also be a NFC as those nodes are not created by the old demangler.
My plan is to keep the old and new mangling implementation in parallel for some time. After that we can remove the old mangler.
Currently the new implementation is scoped in the NewMangling namespace. This namespace should be renamed after the old mangler is removed.
Trying to contain it in SIL doesn't really work if we want to be able to print or parse SIL box types, since the type parser and printer doesn't otherwise depend on the SIL module.
The scope map models all of the name lookup scopes within a source
file. It can be queried by source location to find the innermost scope
that contains that source location. Then, one can follow the parent
pointers in the scope to enumerate the enclosing scopes.
The scope map itself is lazily constructed, only creating scope map
nodes when required implicitly (e.g, when searching for a particular
innermost scope) or forced for debugging purposes.
using a lazily-constructed tree that can be searched by source
location. A search within a particular source location will
A GenericEnvironment stores the mapping between GenericTypeParamTypes
and context archetypes (or eventually, concrete types, once we allow
extensions to constrain a generic parameter to a concrete type).
The goals here are two-fold:
- Eliminate the GenericTypeParamDecl::getArchetype() method, and
always use mapTypeIntoContext() instead
- Replace SILFunction::ContextGenericParams with a GenericEnvironment
This patch adds the new data type as well as serializer and AST
verifier support. but nothing else uses it yet.
Note that GenericSignature::get() now asserts if there are no
generic parameters, instead of returning null. This requires a
few tweaks here and there.
Now that I am going to be adding an IN_SWIFT_COMPONENT argument, I need to do
this to distinguish the concepts of an LLVM_COMPONENT and a SWIFT_COMPONENT.
Stub out a simplistic 'meet' operation for types that currently only
handles finding the meet of two class types. Use it to optimize the
constraint solver ever so slightly: when we see a type variable whose
constraints state that it is a supertype of two different concrete
types, we attempt to compute their meet and, if we find it, only
produce one potential binding that is the meet itself.
Note that this is an extremely poor implementation of this concept
that is meant to address a specific regression being introduced by the
defaulting of collection literal element types. A real implementation
would, at the very least:
* Implement a proper 'meet' that covers all subtyping in the language.
* Distinguish between "I don't know if there is a meet" and "I am
absolutely certain that there is no meet".
* Collapse the constraints themselves to reduce the number of
constraints in the system, rather than just the number of type
variable bindings we attempt.
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.
In 859b779 some changes were made which improved the situation, but we
still have an issue with the order libraries are specified for
linking. Since AST depends on clangCodeGen, which depends on
LLVMCoverage, add LLVMCoverage here as an explicit dependency. It seems
like that dependency is missing (from CMake's perspective), which is why
we end up with an arbitrary order for those two libraries.
The patch:
1. Removes swift's cpack configuration. We do not use cpack anymore, but LLVM
does so including it twice causes problems. Its simpler to just remove it.
2. Ensures that when building swiftAST standalone, we add
dependencies on Clang's tablegen targets.
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
