If a subclass overrides methods with variance in the optionality of non-class-type members, emit a thunk to handle wrapping more optional parameters or results and force-unwrapping any IUO parameters made non-optional in the derived. For this to be useful, we need IRGen to finally pay attention to SILVTables, but this is a step on the way to fixing rdar://problem/19321484.
Swift SVN r24705
There's also a testing option, -serialize-debugging-options, to force this
extra info to be serialized even for library targets. In the long run we'll
probably write out this information for all targets, but strip it out of
the "public module" when a framework is built. (That way it ends up in the
debug info's copy of the module.)
Incidentally, this commit includes the ability to add search paths to the
Clang importer on the fly, which is most of rdar://problem/16347147.
Unfortunately there's no centralized way to add search paths to both Clang
/and/ Swift at the moment.
Part of rdar://problem/17670778
Swift SVN r24545
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
These are the same dependencies collected for .d files, including
headers and imported swiftmodules. These can also cause a file to be out
of date.
Part of rdar://problem/19270920
Swift SVN r24334
This refactoring is groundwork for saving the cross-module dependencies
in the swiftdeps files as well, so that we know to rebuild files if an
outside file changes (such as a bridging header, another framework's
headers, or another framework's swiftmodule).
Part of rdar://problem/19270920
Swift SVN r24258
This flag enables one to specify a json file that expresses a specific
pipeline in the following format:
[
[
"$PASS_MANAGER_ID",
"run_n_times"|"run_to_fixed_point",
$NUM_ITERATIONS,
"$PASS1", "$PASS2", ...
],
...
]
This will make it easier to experiment with different pass pipelines by
allowing:
1. Automatic generation of pass pipelines without needing to recompile
the compiler itself.
2. Simple scripting of pass pipelines via the json meta language.
3. Enabling the easy expression and reproducability of a specific
pipeline ordering via radar.
In the next commit I will provide a python library for the generation of these
json files with a few types of pipeline generators already created.
Swift SVN r24055
...and then honor them.
While here, make -l a little more flexible (see interpret_with_options test).
rdar://problem/17830826, which unblocks the LLDB feature for the same.
Swift SVN r24033
This is a hidden frontend-only option intended for debugging purposes,
mainly for identifying where in a file the type checker is spending most
of its time. Use with "sort -g" to get the top problem functions.
Swift SVN r23789
This does not have any tests since I am going to start going through SILGen
tests and updating them for guaranteed self as the appropriate tests.
*NOTE* There is more work to be done in terms of thunks, but the basic
functionality is done.
rdar://15729033
Swift SVN r23653
This should have been done a long time ago since SILOptions are options that
should be able to effect everything SIL related. In this case I just want to
pass in a flag on the SILModule to enable +0 self. By putting it on the
SILModule I can conveniently check it in SILFunctionType without exposing any
internal state from SILFunctionType.cpp.
Swift SVN r23647
Objective-C method unintended override checking is one such case where
properly checking unintended overrides requires us to essentially look
at the whole module, because one translation unit may declare
something that produces an Objective-C method "setFoo:" in a
superclass while another translation unit declares something with a
distinct name that produces an Objective-C method "setFoo:". So, when
we don't have a primary file (e.g., when we're doing the merge-module
step), delay such checks until after all the source files for the
module have been type-checked. When there is a primary file, we
perform the checking that we can based on type checking that primary
file (and whatever got touched along the way), so we get a subset of
the proper diagnostics.
Swift SVN r23179
This currently handles owned -> guaranteed argument conversion and dead argument
elimination.
RecursiveOwnedParameter||90.0%
ClassArrayGetter|||||||||23.3%
Life|||||||||||||||||||||16.7%
Prims||||||||||||||||||||11.2%
StringWalk|||||||||||||||5.7%
The next step is to implement SROA and address -> value optimizations.
rdar://16917049
Swift SVN r23023
This tracks top-level qualified and unqualified lookups in the primary
source file, meaning we see all top-level names used in the file. This
is part of the intra-module dependency tracking work that can enable
incremental rebuilds.
This doesn't quite cover all of a file's dependencies. In particular, it
misses cases involving extensions defined in terms of typealiases, and
it doesn't yet track operator lookups. The whole scheme is also very
dependent on being used to track file-level dependencies; if C is a subclass
of B and B is a subclass of A, C doesn't appear to depend on A. It only
works because changing A will mark B as dirty.
Part of rdar://problem/15353101
Swift SVN r22925
The name -gnone was chosen by analogy with -O and -Onone. Like -O/-Onone,
the last option on the command line wins.
The immediate use case for this is because we want to be able to run the
tests with -g injected into every command line, but some tests will fail
when debug info is included. Those particular tests can be explicitly marked
-gnone.
rdar://problem/18636307
Swift SVN r22777
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
