The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
The idea so to split solving into non-recursive steps,
represented by `SolverStep`, each of the steps is resposible
for a unit of work e.g. attempting type variable or
disjunction bindings/choices.
Each step could produce more work via "follow-up" steps,
complete "partial" solution when it's done, or error which
terminates solver loop.
A fix is related to one of the constraints through its locator,
and contains information required to "fix" a failure associated with
given constraint, each of the fixes also includes diagnostic.
There is a lot of code involved in inferring and checking @objc that
was tangled with other checking for declarations and types. Move it
into its own source file with a more narrowly-defined interface. NFC
Sink the type checker request classes into the AST library, so that
various functions in the AST library can form type-checking requests.
The actual evaluator functions for these requests continue to live
in the Sema library, called via indirection through the function
pointer tables registered with the request-evaluator.
Wire up the request-evaluator with an instance in ASTContext, and
introduce two request kinds: one to retrieve the superclass of a class
declaration, and one to compute the type of an entry in the
inheritance clause.
Teach ClassDecl::getSuperclass() to go through the request-evaluator,
centralizing the logic to compute and extract the superclass
type.
Fixes the crasher from rdar://problem/26498438.
The initial version of the debugger testing transform instruments
assignments in a way that allows the debugger to sanity-check its
expression evaluator.
Given an assignment expression of the form:
```
a = b
```
The transform rewrites the relevant bits of the AST to look like this:
```
{ () -> () in
a = b
checkExpect("a", stringForPrintObject(a))
}()
```
The purpose of the rewrite is to make it easier to exercise the
debugger's expression evaluator in new contexts. This can be automated
by having the debugger set a breakpoint on checkExpect, running `expr
$Varname`, and comparing the result to the expected value generated by
the runtime.
While the initial version of this testing transform only supports
instrumenting assignments, it should be simple to teach it to do more
interesting rewrites.
There's a driver script available in SWIFT_BIN_DIR/lldb-check-expect to
simplfiy the process of launching and testing instrumented programs.
rdar://36032055
Implements the minimum specified by the SE-proposal.
* Add the CaseIterable protocol with AllCases associatedtype and
allCases requirement
* Automatic synthesis occurs for "simple" enums
- Caveat: Availability attributes suppress synthesis. This can be
lifted in the future
- Caveat: Conformance must be stated on the original type
declaration (just like synthesizing Equatable/Hashable)
- Caveat: Synthesis generates an [T]. A more efficient collection
- possibly even a lazy one - should be put here.
The current implementation isn't really useful in the face of generic
overloads. It has never been enabled by default, and isn't useful to
keep around if it is disabled. If we ever want to bring it back,
we know where to look!
* 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.
Specifically, it uses SerializedASTFile::getLanguageVersionBuiltWith
to improve diagnostics. Not having this has led to failures on Linux,
where linking order matters.
Split out the code for selecting potential bindings into a separate file
as a first step before refactoring it for improved clarity and ease of
modification.
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
Track the types we've seen instead of the type declarations we've
passed through, which eliminates some holes relating to generic types.
Detect infinite expansions by imposing an arbitrary limit.
Fixes rdar://30355804
This is disabled by default but enabled under the frontend option
-propagate-constraints.
The idea here is to have a pass that enforces local consistency in our
constraint system, in order to reduce the domains of constraint
variables, speeding up the solving of the constraint system.
The initial focus will be on reducing the size of the disjunctions for
function overloads with the hope that it substantially improves the
performance of type checking many expressions.
Add an option to the lexer to go back and get a list of "full"
tokens, which include their leading and trailing trivia, which
we can index into from SourceLocs in the current AST.
This starts the Syntax sublibrary, which will support structured
editing APIs. Some skeleton support and basic implementations are
in place for types and generics in the grammar. Yes, it's slightly
redundant with what we have right now. lib/AST conflates syntax
and semantics in the same place(s); this is a first step in changing
that to separate the two concepts for clarity and also to get closer
to incremental parsing and type-checking. The goal is to eventually
extract all of the syntactic information from lib/AST and change that
to be more of a semantic/symbolic model.
Stub out a Semantics manager. This ought to eventually be used as a hub
for encapsulating lazily computed semantic information for syntax nodes.
For the time being, it can serve as a temporary place for mapping from
Syntax nodes to semantically full lib/AST nodes.
This is still in a molten state - don't get too close, wear appropriate
proximity suits, etc.
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.
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.
Piggybacks some resilience diagnostics onto the availability
checking code.
Public and versioned functions with inlineable bodies can only
reference other public and internal entities, since the SIL code
for the function body is serialized and stored as part of the
module.
This includes @_transparent functions, @_inlineable functions,
accessors for @_inlineable storage, @inline(__always) functions,
and in Swift 4 mode, default argument expressions.
The new checks are a source-breaking change, however we don't
guarantee source compatibility for underscored attributes.
The new ABI and tests for the default argument model will come in
subsequent commits.
Based off the PlaygroundTransform, this new ASTWalker leaves calls to __builtin_pc_before and __builtin_pc_after before and after a user would expect a program counter to enter a range of source code.
When referencing a function in the type checker, drop argument labels
when we don't need them to type-check an immediate call to that
function. This provides the semantic behavior of SE-0111, e.g.,
references to functions as values produce unlabeled function types,
without the representational change of actually dropping argument
labels from the type system.
At the moment, this only works for bare references to functions. It
still needs to be pushed through more of the type checker and more AST
nodes to work in the general case.
Keep this work behind the frontend flag
-suppress-argument-labels-in-types for now.
This also adds some tests for the existing generic parameter
capture logic, which was only tested as part of SILGen tests
until now.
Also, move capture analysis into a new TypeCheckCaptures.cpp file.
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.
Implement the Objective-C #keyPath expression, which maps a sequence
of @objc property accesses to a key-path suitable for use with
Cocoa[Touch]. The implementation handles @objc properties of types
that are either @objc or can be bridged to Objective-C, including the
collections that work with key-value coding (Array/NSArray,
Dictionary/NSDictionary, Set/NSSet).
Still to come: code completion support and Fix-Its to migrate string
literal keypaths to #keyPath.
Implements the bulk of SR-1237 / rdar://problem/25710611.
Put in some rudimentary logic for finding circular references within
the iterative type checker and diagnosing those cycles. The
"rudimentary" part is because we're performing linear searches within
a stack rather than keeping a proper dependency graph, which is
inefficient and could display longer cycles than are actually
present. Additionally, the diagnostic is not specialized to the actual
query, so we get a generic "circular reference" diagnostic. OTOH, we
show all of the declarations involved in the cycle, which at least
lets the user figure out where the cycle occurred.
Enable the iterative type checker for resolving the type of a global
typealiases.
Swift SVN r32572
Introduce a request kind for resolving a TypeRepr, and teach type
resolution the start of performing "structural" resolution of a
TypeRepr that gets the basic structure (e.g., we're pointing at
something that is a nominal type, etc.) without checking its
semantics, dealing with generic arguments, etc.
None of this is active yet.
Swift SVN r32569
This is all effectively NFC, but lays out the shape of the iterative
type checker: requests are packaged up in TypeCheckRequest, we can
check whether the request has been satisfied already (isSatisfied),
enumerate its dependencies (enumerateDependenciesOf) in terms of other
TypeCheckRequests, and satisfy a request (satisfy).
Lazily-computed semantic information is captured directly in the
AST, but has been set aside in its own structure to allow us to
experiment with moving it into a lookaside table.
The only request that exists now is to type-check the superclass of
the given class. It currently performs unhealthy recursion into the
existing type checker. As we detangle dependencies, this recursion
between the IterativeTypeChecker and the TypeChecker can go away.
Swift SVN r32558
Provide compiler-synthesized implementations of ErrorType that use the type name as domain and a per-case integer as code. (TBD would be some mapping of the associated data to userInfo in Cocoa.)
Swift SVN r26780
