swift_old will stick around for another week at least for A/B testing.
After that, "swift -frontend" will handle the low-level stuff, and
"swift -force-single-frontend-invocation" will do a high-level build
in the style of swift_old.
Swift SVN r13804
This eliminates a pile of extra casting when interacting with
Objective-C APIs. Addresses the majority of <rdar://problem/14044307>,
but there is still cleanup to do.
Swift SVN r13780
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
Added -debug-assert-immediately and -debug-crash-immediately, which cause an
llvm_unreachable or LLVM_BUILTIN_TRAP to execute during argument parsing.
Added -debug-assert-after-parse and -debug-crash-after-parse, which cause an
llvm_unreachable or LLVM_BUILTIN_TRAP to execute after calling
CompilerInstance::performParse().
This fixes <rdar://problem/16013025>.
Swift SVN r13653
This is the last major Objective-C declaration kind that shows up in
printing bridged Swift classes!
As we modify our set of permitting parameter types, we'll need to continue
adding special cases so that they come out reasonable, but the major
infrastructure work here is pretty much complete.
Swift SVN r13649
Forward-declaring a non-@objc class seems like the right thing to do, but
that could cause a name conflict with an existing @objc class (either
from Clang or from another module). Just use 'id' (and 'Class') to refer
to these.
Swift SVN r13645
All properties are considered nonatomic. If a property comes from Objective-C,
the accessor names may be customized, so always print them out in that case.
Swift SVN r13644
specialize on polymorphic arguments.
This can be enabled with: -sil-devirt-threshold 500.
It currently improves RC4 (when enabled) by 20%, but will be much more
important after Michael's load elimination with alias analysis lands.
This implementation is suitable for experimentation. Superficial code
reviews are also welcome. Although be warned that the design is overly
complex and I plan to rewrite it. I initially abandoned the idea of
incrementally specializing one function at a time, thinking that we
need to analyze full chains. However, I since realized after talking
to Nadav that the incremental approach can be made to work. A lot of
book-keeping will go away with that change.
TODO:
- Resolve protocol argument types. Currently we assume they can be
reinitialized at applies, but I don't think they can unless they are
@inouts. This is an issue with the existing local devirtualizer
that prevents it working across calls.
- Properly mangle the specialized methods. Find existing
specializations by demangling rather than maintaining a map.
- Rewrite the logic for specializing chains for simplicity.
- Enable by default.
Swift SVN r13642
PassManager.
I think this is much cleaner and more flexible. The various pass
builders have no business marshalling these things around, and they
shouldn't be bound to the pass C'tor. In the future we will be able
override and dynamically modify pass configuration this way.
Swift SVN r13626
A single argument specified as "func foo(_: Int)" gets its input parameters
represented as a ParenPattern around a TypedPattern, not a TuplePattern.
Swift SVN r13543
We don't print properties at all right now, but trying to print accessors
results in output with "(null identifier)" where a selector piece should be.
Swift SVN r13542
This re-applies r13380, reverted in r13406. I don't think this actually
caused any harm (r13400 was the primary culprit), but if it did I'd
like to actually see the buildbots or someone else's machine fail on it.
Swift SVN r13456
This substitutes swift_driver in as the new "swift". Tests that currently
test "%swift" will invoke "swift -frontend", much like "clang -cc1".
Most command-line interaction will look the same, except that Swift can
now emit linked libraries (using -emit-library) and executables (using
-emit-executable, or by not passing a mode option at all).
If you are working with @transparent functions, note that they will not be
properly inlined across file boundaries unless you use
-force-single-frontend-invocation, which emulates the old swift binary.
There are Radars for this already: <rdar://problem/15366167&15693042>
The name 'swift_driver' is now a symlink for 'swift'. This will be removed
next week.
The old 'swift' is still available as 'swift_old', though it is not being
tested at all. This will be removed in two weeks.
Clean CMake builds will get this immediately.
Incremental CMake builds will not get the new driver unless you explicitly
enable the SWIFT_NEW_DRIVER option (-DSWIFT_NEW_DRIVER=ON on the command line).
This option will go away in a week.
Makefile builds will get this immediately because I didn't want to work out
how to maintain both modes.
Much credit to Connor for bringing up the entire driver and for doing much
of the work in ensuring that all the tests continue to pass.
Swift SVN r13380
Everything currently using "%swift" now invokes "swift_driver -frontend",
which is the new driver's equivalent of "clang -cc1".
Add a SWIFT_NEW_DRIVER mode to the CMake build.
Building with this set to ON will use the new driver for everything.
In this mode, tests currently using "%swift" will now invoke
"swift_driver -frontend", which is the new driver's equivalent of
"clang -cc1".
The only real change here is that the new driver uses "--" to pass arguments
to interpreted files, while the old one used "--args". Tests should use "--".
This will become the default very soon.
Swift SVN r13266
Prior to r13134, the modules being constructed for IRGen always used the
LLVM global context due to <rdar://problem/15283227>, but the interface
should really take this as a parameter rather than baking the behavior
into IRGen.
Swift SVN r13260
I am going to use this in a forthcoming patch which creates a special mode
called "ParanoidVerification" which runs the verifier after all passes.
"ParanoidVerification" will be by default off and will be used on the swift-fast
buildbot to help catch bugs which might be hidden by optimizations being run.
Swift SVN r13256
SILSerializeAll and EmitVerboseSIL are /not/ being moved because they are
options controlling the output, not about SILGen and SIL passes.
No functionality change.
Swift SVN r13197
Plumbing this through to the inliner necessitated the creation of a
SILOptions class (like FrontendOptions and IRGenOptions). I'll move
more things into this soon.
One change: for compatibility with the new driver, the option must be
specified as "-sil-inline-threshold 50" instead of "-sil-inline-threshold=50".
(We're really trying to be consistent about joined-equals vs. separate
in the new frontend.)
Swift SVN r13193
...and probably should not be emitted before optimization passes.
The new frontend got this wrong, and the old one pretended to allow it but
then silently didn't write a module at all.
Swift SVN r13189
