The last remaining case was apparently @objc generic classes, which
seem to work now.
Also nuke the IRGen/unimplemented_objc_generic_class.swift test,
this is now implemented and we have other tests that test this
functionality.
Swift SVN r29138
Now that we are using OptionSetType for option sets, all the support for
doing things the old way can die.
Note: the fix-it that used to apply to RawOptionSetType, it seemed to me,
should still apply to OptionSetType, so I switched it over instead of
removing it.
Swift SVN r29066
When -enable-simd-import is active, if we encounter a vector type, try to load the SIMD Swift module, and if successful, map float, double, and int vectors to SIMD.{Float,Double,Int}N types if they exist.
Swift SVN r27367
Previously, the only way to get initializers was completing after the
name of the type:
Foo#^complete_here^#
Foo(#^or_here^#
And now it will also work in unadorned expressions:
#^a_top_level_completion^#
bar(a, #^walked_into_a_bar^#
Unfortunately, not all our clients handle this well yet, so it's
protected by a language option.
-code-complete-inits-in-postfix-expr
Swift SVN r27275
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
We're not going to require the type parameters to be redeclared on
extensions of generic types, so take away the staging option and
diagnostic.
Swift SVN r26854
In particular, this is problematic when libraries are loaded dynamically, and
may have newer deployment targets than the main executable.
Swift SVN r26786
...which allows "@testable import" to work with modules not compiled for
testing. This isn't generally safe, but should be fine for clients like
SourceKit which just need to have the API available and might not be able
to properly rebuild the original target for testing.
We may revisit this in the future.
Swift SVN r26629
This flag enables checking of availability (deprecation, explicit unavailability,
and potential unavailability) in synthesized functions. The flag will go away once this
checking is fully staged in.
Swift SVN r26624
SIL seems to be doing the right thing here already, which is great!
Part of rdar://problem/17732115. We'll be able to really see this working
with the next change: allowing references to testable things when using
"@testable import".
Swift SVN r26473
This warning is temporarily going being a flag so that, once it is safe to place generic parameters on extensions of generic types, we can opt-in to update our code when it is convenient.
Swift SVN r26416
This flag indicates that internal APIs within the module should be made
available to client code for testing purposes. Currently does nothing.
Not ready for developer consumption yet, ergo a hidden frontend-only flag.
Part of testability (rdar://problem/17732115)
Swift SVN r26292
Together with -wmo it enables multi-threaded compilation.
I didn't want to reuse the -j option for this, because -num-threads (even if n == 1) does change the generated code.
For details see commit message of r25930.
Swift SVN r26258
Since a function pointer doesn't carry any context, we can only form a C function pointer from a static reference to a global function or a context-free local function or closure. (Or maybe a static function applied to its metatype, but that's not handled here yet.) As a placeholder for a to-be-bikeshedded surface syntax, let the existing @cc(cdecl) attribute appear in source text when the -enable-c-function-pointers frontend flag is passed.
Swift SVN r25308
We've had a rash of bugs due to inconsistencies between how IRGen and the runtime think types are laid out. Add a '-verify-type-layout' mode to the frontend that causes IRGen to emit a bunch of code that compares its static assumptions against what the runtime value witness does.
Swift SVN r24918
This implicitly adds the named module as an import of every source file
in the module being compiled. This is not intended to be used generally,
but will be useful for playgrounds.
rdar://problem/19605934
Swift SVN r24905
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 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
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 was being staged as -emit-reference-dependencies, but it's affecting
a lot more than that. Eventually for command line builds this should also
preserve intermediate build outputs (like .o and .swiftmodule) for use in
later builds, rather than putting them in $TMPDIR and deleting them after.
This option is still hidden.
Swift SVN r23295
This just adds another possible output kind and forwards it to the frontend.
Note that in builds without an output map, this will just dump the dependencies
next to the output file, which is a temp file whose name is chosen randomly.
That's not so useful, but we can fix it later.
Part of rdar://problem/15353101
Swift SVN r23220
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
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
