Whenever we add a requirement, we now know
(1) Why we added the requirement, e.g., whether it was explicitly written, inferred from a signature, or introduced by an outer scope.
(2) Where in the source code that requirement originated.
Also add a debugging flag for dumping the archetype builder information, so we can write tests against it.
This is effectively NFC, but it's infrastructure to help a number of requirements-related tasks.
Swift SVN r22638
Previously we hardcoded a few important default CPUs, ABIs, and features into
Swift's driver, duplicating work in Clang. Now that we're using Clang's
driver to create the Clang "sub-compiler", we can delegate this work to Clang.
As part of this, I've dropped the options for -target-abi (which was a
frontend-only option anyway) and -target-feature (which was a hidden driver
option and is a frontend-only option in /Clang/). We can revisit this later
if it becomes interesting. I left in -target-cpu, which is now mapped
directly to Clang's -mcpu=.
Swift SVN r22449
This patch adds the ability (-enable-experimental-unavailable-as-optional) to
treat potentially unavailable declarations as if they had optional types. For
the moment, this is only implemented for global variables.
The high-level approach is to (1) record the potential unavailability of a
declaration reference in the overload choice during constraint generation; (2)
treat the declaration as if it had an optional type during overload resolution
(this is similar to how optional protocol members are treated); and (3) add an
implicit conversion (UnavailableToOptionalExpr) during constraint application
to represent the run-time availability check and optional injection.
This patch does not implement SILGen for UnavailableToOptionalExpr.
Swift SVN r22245
for testing purposes.
When enabled, if the typechecker tries to typecheck a decl or unresolved identifier with the provided
prefix, then an llvm fatal_error will get triggered.
This approach has the advantage that it is very easy to write tests for unnecessary typechecking for a wide range of functionality,
for the compiler or SourceKit, for code-completion, indexing, etc.
Swift SVN r22003
This patch fixes a problem where a CompilerInvocation
with no arguments would set the LangaugeOpts etc. up for
the deprecated-integrated-repl, including setting the
module name etc. Now this only happens if you explicitly
invoke swift -frontend -repl.
Updated testcases that care, and added a new testcase to
ensure that an error is properly generated.
<rdar://problem/17918172>
Swift SVN r21537
This enables us to parse dumped .sil files with swiftc. Before this
commit we could parse them with sil-opt, but not swiftc.
rdar://17860394
Swift SVN r21492
Also, use 'Playground' to control the behavior of ignored expressions
(which are not an error because they are displayed in the playground log).
This is preparation for LLDB no longer passing 'DebuggerSupport' for a
playground <rdar://problem/18090611>. 'DebuggerSupport' now only applies
to REPL-like contexts and enables identifiers beginning with $, special
rules for parsing top-level code, ignored expressions (like playgrounds),
and the @LLDBDebuggerSupport attribute.
Besides ignored expressions, 'Playground' enables the playground transformation
and provides an entry point for debugger initialization.
Note that this is a bit insincere---many of the options controlled by both
'Playground' and 'DebuggerSupport' really only apply to the main source file
or main module. If/when we add back support for source file imports, we'll
need to revisit all of LangOptions and see which of them should /really/
apply to /everything/ in the ASTContext.
Swift SVN r21384
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
This is enabled by default because SILGen can crash when @objc is used without importing Foundation, but
it gets disabled when compiling the Swift stdlib.
Addresses rdar://17931250.
Related test case on the SourceKit side.
Swift SVN r21319
When a subclass is missing a required initializer, produce an error
within the subclass that mentions the required initializer along with
a Fix-It that provides an initializer stub, e.g.,
required init(coder aDecoder: NSCoder!) {
fatalError("init(coder:) has not been implemented")
}
We take care to insert this stub in the main class, after all of the
initializers (if there are any) or near the beginning of the class (if
there aren't any initializers), and try to match the existing
indentation. If this works out, we should handle unsatisfied protocol
requirements the same way. <rdar://problem/17923210>
Swift SVN r21055
While we work out the remaining performance improvements in the type checker, we can improve the user experience for some "runaway solver" bugs by setting a limit on the amount of temporary memory allocated for type variables when solving over a single expression.
Exponential behavior usually manifests itself while recursively attempting bindings over opened type variables in an expression. Each one of these bindings may result in one or more fresh type variables being created. On average, memory consumption by type variables is fairly light, but in some exponential cases it can quickly grow to many hundreds of megabytes or even gigabytes. (This memory is managed by a distinct arena in the AST context, so it's easy to track.) This problem is the source of many of the "freezing" compiler and SourceKit bugs we've been seeing.
These changes set a limit on the amount of memory that can be allocated for type variables while solving for a single expression. If the memory threshold is exceeded, we can surface a type error and suggest that the user decompose the expression into distinct, less-complex sub-expressions.
I've set the current threshold to 15MB which, experimentally, avoids false positives but doesn't let things carry on so long that the user feels compelled to kill the process before they can see an error message. (As a point of comparison, the largest allocation of type variable data while solving for a single expression in the standard library is 592,472 bytes.) I've also added a new hidden front-end flag, "solver-memory-threshold", that will allow users to set their own limit, in bytes.
Swift SVN r20986
Teaches TryAddFinal to descend into public and objc classes. Only
tries to add final if we're either whole compilation mode, or we're
processing the primary source buffer.
Updates test cases. Includes workarounds for <rdar://problem/17860781>
and <rdar://problem/17862348>.
Swift SVN r20790
Without this, clients that don't use a CompilerInstance (like LLDB) won't
have target configuration options available.
Also, move minimum OS checking into the driver. This makes sure the check
happens early (and only once), and in general fits the philosophy of
allowing the frontend to use configurations that might be banned for users.
<rdar://problem/17688913>
Swift SVN r20701
is typically disabled when compiling normally,
and thereby emit and check for class initialization
without interfering with PlaygroundTransform
testcases that use classes.
Swift SVN r20659
Revert "For debugging purposes allow passes to stop any more passes from running by calling PassManager::stopRunning()."
This reverts commit r20604.
This reverts commit r20606.
This was some debugging code that snuck in.
Swift SVN r20615
This is the first testcase and includes the test
harness which will work for other testcases as
well.
Also includes a fix to make sure that we only
instrument once per main source file, and not
once per parse as we were doing before.
Swift SVN r20456
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
Run whole-module checks at the end of perform Sema, specifically
TryAddFinal. After everything has been type checked, accessibility has
been provided, and we have had a chance to see any potential
overrides, we try to add the final attribute to class members.
This ends up de-virtualizing many functions, or rather they avoid the
vtable altogether. Thus, there are many test file changes. New test
file add_final.swift. Other tests updated to either reflect the
non-virtual call, or to have public added to them.
Swift SVN r20338
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
