ASan allows to catch and diagnose memory corruption errors, which are possible
when using unsafe pointers.
This patch introduces a new driver/frontend option -sanitize=address to enable
ASan. When option is passed in, the ASan llvm passes will be turned on and
all functions will gain SanitizeAddress llvm attribute.
Previously jobs had to grovel this information out of the raw argument
list, which dropped the types we had inferred on input files. This
makes things more consistent across the compiler, though arguably we
should be able to designate "primary" and "non-primary" inputs on a
per-action basis rather than resorting to "global" state.
Use this new information to stop passing object file inputs to the
Swift frontend, fixing rdar://problem/23213785.
The list wouldn't have to live on the Compilation, but I'm going to use
it to fix SR-280 / rdar://problem/23878192 as well.
Also, cluster the flags on Action into a single word. This probably doesn't
make any real difference, but it's the convention.
No functionality change.
DerivedArgList has a pointer to the InputArgList it came from, so we can't
just std::move it around. Put most of the driver back the way it was, with
small changes to clarify ownership.
Swift SVN r31811
This was just a wrapper around SmallVector that optionally owned the Job pointers
in it. Now that all Jobs are owned by the Compilation, we don't have to worry
about this any more.
No functionality change.
Swift SVN r29668
...not if it's newer than its output .o file. This handles cases where the
object file is generated too quickly (rdar://problem/19404140) or when you
revert to a previous version of the file, mtime intact (rdar://problem/19720146).
There's a lot of test churn here; the only real new test is the backwards
mtime update in one-way.swift.
Swift SVN r29584
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
These aren't inherently incompatible, but today it would do nothing useful,
and using both flags together causes problems (see previous commit).
rdar://problem/19669432
Swift SVN r25389
Also, normalize the target triple up front, so that we're never dealing
with non-normalized triples in the driver unless explicitly asking for
the original user option.
rdar://problem/18065292
Swift SVN r24563
If certain command-line arguments change, the results of the last
compilation aren't reusable, i.e. we can't do an incremental build.
Do a full rebuild when we detect that this happens.
(Which command-line options? Conservatively assume all of them, /except/
those with the new DoesNotAffectIncrementalBuild flag in Options.td.)
Swift SVN r24385
of 'bin/swift-update' with the related frontend options.
'swift-update' will be the tool for producing diffs to update swift code to the
latest version.
Swift SVN r24287
r23968 wrote out a record of which source files were included in a build,
and whether they were succesfully compiled or not...and if not, whether
they were out of date because of a cascading or non-cascading dependency.
This commit uses that information to decide what files might need to be
rebuilt even if a particular input doesn't change and doesn't appear to
have any changed dependencies. The two interesting cases are:
- A file was going to be built last time, but the build was halted
because of an error. Build it this time.
- One of the files was removed and thus we've lost a source of dependency
information; rebuild everything!
rdar://problem/19270980
Swift SVN r24018
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
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
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 emits a dynamic library as the final build product (rather than an
executable), as well as implicitly passing -parse-as-library to the frontend.
Swift SVN r12930
...when no -module-name or -o is provided.
This makes the single-file compile /very/ easy: compiling "foo.swift"
produces an output named "foo", rather than "a.out". For multi-file
modes, the module name is used if -o is missing; if no module name is
provided, it defaults to "main".
In a nutshell:
explicit -o > explicit -module-name > single file's stem name > "main"
<rdar://problem/12593849>
Swift SVN r12841
Centralized the driver-level handling of the SDK path in OutputInfo and
Driver::buildOutputInfo(), and added support for falling back to getenv(SDKROOT)
if -sdk wasn't passed (and SDKROOT is set in the environment).
Updated Swift::constructJob() to get the SDK path from the OutputInfo instead of
just passing -sdk from the original driver invocation.
Also added a driver-level check to ensure that the specified SDK is present;
if not, print out a warning. This fixes <rdar://problem/14409974>.
Added test/Driver/sdk.swift to test the -sdk and SDKROOT behavior, as well as
the nonexistent SDK warning.
Swift SVN r12815
Added an -output-file-map option which will specify the path to an
OutputFileMap.
Added Driver::buildOutputFileMap(), which constructs an OutputFileMap
from the arguments.
Added OutputFileMap* parameters to Driver::buildJobs() and
Driver::buildJobsForAction(). (These parameters are not yet honored, except to
pass to calls of these functions.)
Swift SVN r12772
This sets OutputInfo::CompilerMode to a new SingleCompile mode, which in turn
causes the driver to create a single CompileJobAction for all inputs. This mode
also prevents the creation of a MergeModuleJobAction, since we can rely on the
frontend to generate a full swiftmodule.
This mode will allow the driver to properly compile the stdlib; if this mode is
necessary for other inputs, we can rename and publicize this option.
Swift SVN r12612
Introduced OutputInfo::Mode and OutputInfo::CompilerMode, which dictate how the
driver should invoke the integrated frontend. Currently, there are three
options:
- StandardCompile: invoke the frontend once-per-input, using -primary-file
- REPL: invoke the frontend as the REPL
- Immediate: invoke the frontend in immediate mode
Updated buildOutputInfo() to properly set the CompilerMode, and updated
buildActions() and Swift::constructJob() to honor the CompilerMode.
With these changes, "swift_driver" (with no inputs) and "swift_driver -repl"
should invoke the REPL, and "swift_driver -i" should invoke the frontend in
immediate mode.
Swift SVN r12547
This will indicate that the generated module was user-requested, so it should be
placed alongside other outputs.
Updated buildOutputInfo() in a few ways:
- Updated it to set ShouldTreatModuleAsTopLevelOutput correctly.
- Updated it such that -g implies that a module should be generated, but treated as an intermediate.
- Moved the fallback ModuleName handling into buildOutputInfo(), which requires passing an InputList.
Swift SVN r12502
