This adds two things:
- Calling `swiftc -dump-ast foo.swift [...] -o foo.ast` will dump the AST to the file `foo.ast`, instead of dumping it to `stderr` as usual.
- Calling `swiftc -dump-ast -output-file-map=outputFileMap.json *.swift [...]`, given an `outputFileMap.json` file that contains entries in the form `"ast-dump": "foo.ast"`, will dump the ASTs of the input files to their respective output files in the file map.
This should serve as a valid workaround to a bug mentioned in [the forums](https://forums.swift.org/t/error-when-dumping-the-ast-for-hundreds-of-files/17578) where the AST dump functionality crashes when called with too many input files. A few implementation details were also discussed in the same forum post.
As an aside, this also fixes a comment in `include/swift/Basic/PrimarySpecificPaths.h` that was incorrect.
This change allows the swift driver to link the ubsan runtime if
`-sanitize=undefined` is specified.
This is useful for sanitizing linked Objective-C code.
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
- Uses version 61.1 from ICU Github unicode-org/icu repository.
- Updates mixin_linux_installation to add libicu option.
- Use -j when building libicu.
- When buiding ICU, use --with-library-suffix=swift
This suffixes the ICU symbols with _swift.
The libaries are now named libicuucswift, libicui18nswift
and libicudataswift.
- Add the contents of uconfig.h.prepend into uconfig.h. This avoids
passing the renaming CFLAGS to swift and swift-corelibs-foundation.
Also resolves:
SR-5618: libicu compilation should happen in parallel respecting -j.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
There's no place to put the bridging header in a swiftinterface, and
they don't make sense with the intended use case of distribution.
Just disallow it up front.
rdar://problem/44113493
Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
This enables response files for any jobs that invoke `swift` or another
toolchain tool that goes through the same driver code path, like
`swift-autolink-extract`.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
StringMap always copies its strings into its own storage. A DenseMap
of StringRefs has the same caveats as any other use of StringRef, but
in the cases I've changed the string has very clear ownership that
outlives the map.
No functionality change, but should reduce memory usage and malloc
traffic a little.
When provided, this flag warns about implicit overrides, where a
declaration overrides another declaration but is not marked with the
‘override’ keyword. The warning can be suppressed by either providing
‘override’ or ‘@_nonoverride’.
At present, this only happens with overrides in protocols.
But not even that much uglier; at all three call sites this will save
an allocation, and for the most important one (SourceKit) we can now
avoid creating a temporary CompilerInvocation just to copy into a
longer-lived one.
With this change, Driver no longer depends on Frontend, which means...
well, slightly faster builds of the compiler itself, but not much
else.
The OutputInfo, ToolChain, and Triple can all be retrieved from the
Compilation, so now that we're passing one of those around we don't
need to pass the others explicitly.
No functionality change.
- Get rid of the singular (*_INCLUDE_DIR and *_LIBRARY) variables and
standardize on the plural ones, since that's also what's used by
CMake's FindICU module (which was added in 3.7).
- Use PKG_CONFIG_FOUND instead of PKGCONFIG_FOUND, since that's what's
documented in CMake's FindPkgConfig module. (The latter will be set by
the find_package call, so it's not incorrect, but it's clearer to use
the documented variable.)
- Search for the headers and libraries even if pkg-config can't find the
module, since e.g. we might have ICU somewhere in our CMake search
path but might not have the pkg-config module for it. We're only using
the pkg-config results as search hints anyway. (This might result in
an empty HINTS argument to find_path and find_library, but CMake seems
to handle that fine.) *This should be the only functional change.*
- Remove ICU_${MODULE}_DEFINITIONS, since it's never used anywhere.
- Don't add the *_INCLUDEDIR and *_LIBDIR variables to the hints, since
they should be the same as the corresponding *_INCLUDE_DIRS and
*_LIBRARY_DIRS variables (since we're only searching for a single
module).
The only intended functional change, as mentioned above, is that we can
now successfully find ICU if its include and library directories are in
the CMake search path but its pkg-config module isn't, which might be
the case in certain cross-compilation or hermetic build scenarios. (It's
compounded by CMake only looking for pkg-config modules in
CMAKE_PREFIX_PATH and not CMAKE_SYSTEM_PREFIX_PATH, which I asked about
in https://cmake.org/pipermail/cmake/2018-August/068109.html).
