The Swift compiler is always fed the entire list of files in a module.
If it's told to track dependencies, though, it should look to see if it
actually needs to recompile all of its inputs. The first step in this is
to see which files are actually dirty, which it does by comparing the mtime
of each source file with the mtime of its output object file. If a source
file is not dirty, it only needs to be rebuilt if it depends on something
in a dirty file.
Nothing actually uses this information yet, but we can print it with
-driver-print-bindings!
Swift SVN r23221
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
...and rename Command to Job (previously the name of the base class).
We never generated job lists directly contained in other job lists, so
let's not even worry about this case. We may some day need to break Job
out into separate subclasses (Clang has Command and FallbackCommand in
addition to JobList), but we should be able to keep the list separate.
No intended functionality change.
Swift SVN r23144
Instead, if we can't schedule a command, record why it was blocked. When the
blocking command completes, we then try to reschedule everything that was
blocked on it.
This is also more robust for cross-job-list dependencies---things like the
link job depending on the merge-module job and both depending on compile jobs.
Swift SVN r23143
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
Actually, reject SDK directories whose names match
"*OSX<version>(.Internal)?.sdk" on OS X with a version older than 10.10
"*OS7*" on iOS
"*Simulator7*" on iOS
We only really care about 10.9 anyway, but just in case people install the
one-previous version of iOS...
<rdar://problem/17951615>
Swift SVN r21100
Added a new API, swift::driver::createCompilerInvocation. This takes an array
of driver arguments, constructs a Driver and a Compilation, and then uses the
Compilation's frontend arguments to create a CompilerInvocation.
This works by forcing Driver to create a Compilation which contains a single
compile command. (It achieves this by passing
"-force-single-frontend-invocation" after all other arguments.) This approach
roughly matches Clang's clang::createInvocationFromCommandLine.
As implied by the namespacing, this lives in swiftDriver. As a result,
swiftDriver now depends on swiftFrontend.
In support of this, added a couple of driver diagnostics for exceptional error
cases (where Driver produced something other than a single Command, or if that
Command is not a frontend command).
This fixes <rdar://problem/16125395>.
Swift SVN r20972
When "-parseable-output" is passed to the driver, it will now emit output in a
parseable format. (This format is described in docs/DriverParseableOutput.rst,
which was added in a previous commit.)
This is achieved by adding four functions (one for each kind of message). These
are in a new swift::driver::parseable_output namespace, and given the right
parameters, will output the appropriate message in JSON to the given
llvm::raw_ostream. These functions are then called by
Compilation::performJobsInList:
- "began" messages are emitted by the taskBegan callback
- "finished" messages are emitted by the taskFinished callback
- "signalled" messages are emitted by the taskSignalled callback
- "skipped" messages are emitted by the handleCommandWhichDoesNotNeedToExecute
lambda
(Note that "skipped" messages will not be emitted in practice, since the driver
does not yet support partial compilation.)
This fixes <rdar://problem/15958329>.
Swift SVN r20873
This level is selected by -parseable-output. This flag is only accepted by
swiftc, since it does not make sense for any of the interactive modes.
(Currently, this level prints out the same information as Verbose, with a
"Command: " string prepended.)
Additionally, in Compilation::performJobs, set RequiresBufferedOutput to true if
parseable output was requested, since parseable output will require buffered
output.
Part of <rdar://problem/15958329>.
Swift SVN r20872
Previously, Verbose output was not produced for this case; it is now, and this
is achieved by making performSingleCommand() a private method on Compilation
instead of a static function.
Swift SVN r20850
There are two valid values for this: 'swift' and 'swiftc'. This flag must be
specified as the first option; otherwise, it will be ignored. This flag allows
the caller of the driver to force 'swift' to behave as 'swiftc', or vice versa,
and is useful in situations where the name of the executable cannot be changed.
Swift SVN r20656
This makes the command line interface to 'swift' the same as what was
previously in 'swifti', and removes the staging symlink.
For posterity, the command line behaviour for 'swift' is now:
* `swift` -> start the repl
* `swift script.swift` -> run script.swift (the old -i mode)
* Any arguments after the input file are forwarded to the script as
Process.arguments
* A shebang line is something like #!/usr/bin/xcrun swift
The batch compiler 'swiftc' behaves much like the old 'swift'
executable, but without the interactive bits now in 'swifti'.
<rdar://problem/17710788>
Swift SVN r20540
This matches Clang's behavior, though this implementation does not check
that it's actually on a platform that uses dsymutil.
<rdar://problem/16012971>
Swift SVN r20529
For now, keep 'swift' the same and put all the interactive driver
changes under 'swifti'. When these are in good shape, I will remove
swifti and make 'swift' the interactive driver as discussed.
Swift SVN r20359
This allows swiftFrontend to drop its dependency on swiftDriver, and could
someday allow us to move the integrated frontend's option parsing out of
swiftFrontend (which would allow other tools which use swiftFrontend to
exclude the option table entirely).
Swift SVN r19824
The driver option -i now requires an input file as argument, and any
options after the input file will be treated as arguments to the
interpretted file.
This also renames the frontend option to -interpret, since it is parsed
as a flag, unlike -i. We could support -interpret in the driver if we
wanted, which would allow us to use --, but wouldn't work with shebang
scripts. For now, it's frontend-only.
Swift SVN r19718
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
optimization/inlining scheme.
It was actually used while building a release version of stdlib, and
effectively disabled safety checks in debug builds.
Swift SVN r19461
Allow a String value to be implicitly converted to ConstUnsafePointer<{UInt8,Int8,Void}> by string-to-pointer conversion, when enabled by a staging flag.
Swift SVN r19366
This applies to both qualified and unqualified lookups, and is controlled
by the -enable-access-control and -disable-access-control flags. I've
included both so that -disable-access-control can be put into specific tests
that will eventually need to bypass access control (e.g. stdlib unit tests).
The default is still -disable-access-control.
Swift SVN r19146
Add primitive type-checker rules for pointer arguments. An UnsafePointer argument accepts:
- an UnsafePointer value of matching element type, or of any type if the argument is UnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is UnsafePointer<Void>, or
- an inout Array parameter of matching element type, or of any type if the argument is UnsafePointer<Void>.
A ConstUnsafePointer argument accepts:
- an UnsafePointer, ConstUnsafePointer, or AutoreleasingUnsafePointer value of matching element type, or of any type if the argument is ConstUnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>, or
- an inout or non-inout Array parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>.
An AutoreleasingUnsafePointer argument accepts:
- an AutoreleasingUnsafePointer value of matching element type, or
- an inout parameter of matching element type.
This disrupts some error messages in unrelated tests, which is tracked by <rdar://problem/17380520>.
Swift SVN r19008
This will enable via the -print-stats function the ability to quickly
find out the final count of various forms of instructions. My intention
is to use this to count retains and releases.
Swift SVN r18946
Allow class metatypes (including class-constrained existential metatypes) to be treated as subtypes of AnyObject, and single-@objc protocol metatypes to be treated as subtypes of the Protocol class from objc. No codegen support yet, so this is hidden behind a frontend flag for now.
Swift SVN r18810
This only works when swift is packaged with Xcode or installed as a command
line tool, but those are the important cases.
<rdar://problem/14395800>, again.
Swift SVN r18757
If we can't determine the type of an input file, we assume it's a linker
input of some sort (like Clang does). However, if we're not actually linking,
this resulted in unused inputs, which the driver choked on.
This commit updates the driver to throw away (and diagnose) inputs that
aren't going to be compiled if they aren't going to be used later on.
It also checks that none of our non-object output types are being treated
as linker inputs, since we do have that information around.
<rdar://problem/16019895>
Swift SVN r18667
Previously, the frontend detected that its output was being piped into the
driver and buffered, and decided that that wasn't a color-friendly output
stream. Now, the driver passes -color-diagnostics to the frontend to force
color output if the driver itself is in a color-output context.
<rdar://problem/16697713>
Swift SVN r18506
I didn't want to rip this logic out wholesale. There is a possibility
the character lexing can be reborn/revisited later, and
disabling it in the parser was easy.
Swift SVN r18102
This turns on bridging of Dictionary<K, V> by default
<rdar://problem/16870606>. The -objc-bridge-dictionary option remains
and currently means "import NSDictionary* as Dictionary<NSObject,
AnyObject>". We'll flip that switch separately.
Swift SVN r17855
If a temporary file is mentioned in the output map, it is also preserved.
We can make a nicer -save-temps later, but for now this will at least stop
leaving random files in /var/tmp.
<rdar://problem/16874893>
Swift SVN r17850
This was originally intended for use with options that were processed by
the driver itself, rather than fed into other tools, but we weren't very
consistent about it and never actually used it for anything.
Swift SVN r17849
