Thread the static build configuration (formed from language options) in
to the macro plugin handler, which will serialize it for use in the
macro implementation. test this with a simple macro that checks
whether a particular custom configuration (set via `-D`) is enabled or
not.
This required some re-layering, sinking the logic for building a
StaticBuildConfiguration from language options down into a new
swiftBasicSwift library, which sits on top of the C++ swiftBasic and
provides Swift functionality for it. That can be used by the C++
swiftAST to cache the StaticBuildConfiguration on the ASTContext,
making it available for other parts of ASTGen.
Ideally this would also update the `--version` output to be overridden
by `SWIFT_TOOLCHAIN_VERSION`, but unfortunately various tools rely on
the current format (eg. swift-build).
This is a replacement for `-emit-supported-features` that prints
all of the upcoming/experimental features supported by the compiler
with some additional meta information in JSON format to stdout.
Use the `clang::TargetInfo` to query the target pointer size for the
given triple. This is meant to enable us to properly determine
`CMAKE_SIZEOF_VOID_P`.
This adds three new assertion macros:
* `ASSERT` - always compiled in, always checked
* `CONDITIONAL_ASSERT` - always compiled in, checked whenever the `-compiler-assertions` flag is provided
* `DEBUG_ASSERT` - only compiled into debug builds, always checked when compiled in (functionally the same as Standard C `assert`)
The new `-compiler-assertions` flag is recognized by both `swift-frontend` and
`swiftc`.
The goal is to eventually replace every use of `assert` in the compiler with one of the above:
* Most assertions will use `ASSERT` (most assertions should always be present and checked, even in release builds)
* Expensive assertions can use `CONDITIONAL_ASSERT` to be suppressed by default
* A few very expensive and/or brittle assertions can use `DEBUG_ASSERT` to be compiled out of release builds
This should:
* Improve quality by catching errors earlier,
* Accelerate compiler triage and debugging by providing more accurate crash dumps by default, and
* Allow compiler engineers and end users alike to add `-compiler-assertions` to get more accurate failure diagnostics with any compiler
Moved out of MemoryLocations.h and merged the implementations of <<,
keeping the version from MemoryLocations with its brackets and commas
available via a flag but defaulting the implementation previously in the
header.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
Add a helper to allow us to programatically extract the Swift version
string during the build. This is particularly useful for injection into
the packaging stages.
Co-authored-by: Evan Wilde <etceterawilde@gmail.com>
Executable compiler plugins are programs invoked by the host compiler
and communicate with the host with IPC via standard IO (stdin/stdout.)
Each message is serialized in JSON, prefixed with a header which is a
64bit little-endian integer indicating the size of the message.
* Basic/ExecuteWithPipe: External program invocation. Lik
llvm::sys::ExecuteNoWait() but establishing pipes to the child's
stdin/stdout
* Basic/Sandbox: Sandboxed execution helper. Create command line
arguments to be executed in sandbox environment (similar to SwiftPM's
pluging sandbox)
* AST/PluginRepository: ASTContext independent plugin manager
* ASTGen/PluginHost: Communication with the plugin. Messages are
serialized by ASTGen/LLVMJSON
rdar://101508815
swiftBasic uses `InFlightDiagnostic::flush`, which is defined in
swiftAST. The build graph did not contain that link edge, so it failed
to link on Windows. No idea how it's working on macOS.
A fingerprint is a stable hash of a particular piece of compiler data. This formalizes the stable notion of identity that the dependency trackers use for type body fingerprints in iterable decl contexts and the file-level interface hash
This PR adds a SWIFT_APPEND_VC_REV Cmake option (in symmetry with LLVM's LLVM_APPEND_VC_REV).
When enabled, lib/Basic/SwiftRevision.inc header contains git commit hash and repository information, e.g.
#define SWIFT_REVISION "ed4cef9b839d4a87618758d8b8705ab66b61917f"
#define SWIFT_REPOSITORY "https://github.com/scentini/swift.git"
This is useful for keeping track of the VCS state that produced a binary. But for local development builds, this information is often ignored and since this file is invalidated by every git commit or git checkout command and it leads to long rebuilds, it's useful to have a switch to disable this behavior. When SWIFT_APPEND_VC_REV is disabled, lib/Basic/SwiftRevision.inc contains:
#undef SWIFT_REVISION
#undef SWIFT_REPOSITORY
Now that we use the LLVM mono-repo, we don't need to worry about clang's
version number. Also, git has the ability to estimate the safe number of
digits a hash can be truncated to and now git estimates that large
projects like LLVM and Linux "require" 12 digits for safe commit hash
abbreviation. Let's stay a little ahead of the curve and statically
truncate to 15.
Use a newly introduced `swift_gyb_target_sources` to gyb and use the
generated sources when building. Let CMake figure out when to run the
command, let it invoke the command properly, and indicate that the
sources being added to the target are generated.
Delete all of the formalism and infrastructure around maintaining our own copy of the global context. The final frontier is the Builtins, which need to lookup intrinsics in a given scratch context and convert them into the appropriate Swift annotations and types. As these utilities have wormed their way through the compiler, I have decided to leave this alone for now.
A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
These changes allow to optionally perform a very fast build that is targeted to only produce the syntax parser library.
Part of addressing rdar://48153331
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
