SILType and SILDeclRef do not actually need anything from SIL/*.h. Also,
a few dependencies can be pushed out of the headers into cpp files to
speed up incremental rebuilds.
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.
Implement a new "fast" dependency scanning option,
`-scan-dependencies`, in the Swift frontend that determines all
of the source file and module dependencies for a given set of
Swift sources. It covers four forms of modules:
1) Swift (serialized) module files, by reading the module header
2) Swift interface files, by parsing the source code to find imports
3) Swift source modules, by parsing the source code to find imports
4) Clang modules, using Clang's fast dependency scanning tool
A single `-scan-dependencies` operation maps out the full
dependency graph for the given Swift source files, including all
of the Swift and Clang modules that may need to be built, such
that all of the work can be scheduled up front by the Swift
driver or any other build system that understands this
option. The dependency graph is emitted as JSON, which can be
consumed by these other tools.
Some code paths that see target triples go through the frontend
without seeing the driver. Therefore, perform the same "simulator"
inference for x86 iOS/tvOS/watchOS triples also in the frontend,
to ensure that we remain compatible. Also make sure that
-print-target-info performs the appropriate adjustment.
The *-simulator target triples have been used consistently in tools for
several years to indicate simulator targets. Stop inferring the
simulator part, rdar://problem/35810403.
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.
Some code paths that see target triples go through the frontend
without seeing the driver. Therefore, perform the same "simulator"
inference for x86 iOS/tvOS/watchOS triples also in the frontend,
to ensure that we remain compatible. Also make sure that
-print-target-info performs the appropriate adjustment.
The *-simulator target triples have been used consistently in tools for
several years to indicate simulator targets. Stop inferring the
simulator part, rdar://problem/35810403.
When mangling sugared types for DWARF debug info, we would
occassionally mix generic parameter types from different
generic environments. Since the mangling for a generic
parameter type only recorded the depth and the index, even
for distinct sugared forms, the remangler would produce a
more 'compact' mangling, by folding together generic parameters
that have the same depth/index, but distinct sugarings in the
AST.
Prevent this from happening by desugaring DWARF types the
correct amount, substituting away generic parameters while
preserving everything else.
Also, re-enable the round-trip verification with the remangler.
Fixes <rdar://problem/59496022>, <https://bugs.swift.org/browse/SR-12204>.
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`.
There were a couple of methods in LangOptions and some related ones in
Availability and ASTContext that were added more recently.
Refactor the three older checks to the newer scheme.
This allows the usage of the whole remark infrastructure developed in
LLVM, which includes a new binary format, metadata in object files, etc.
This gets rid of the YAMLTraits-based remark serialization and does the
plumbing for hooking to LLVM's main remark streamer.
For more about the idea behind LLVM's main remark streamer, see the
docs/Remarks.rst changes in https://reviews.llvm.org/D73676.
The flags are now:
* -save-optimization-record: enable remarks, defaults to YAML
* -save-optimization-record=<format>: enable remarks, use <format> for
serialization
* -save-optimization-record-passes <regex>: only serialize passes that
match <regex>.
The YAMLTraits in swift had a different `flow` setting for the debug
location, resulting in some test changes.
Add the platform conditional and set up other basics for the toolchain.
The ConditionalCompilation tests are updated to match, since otherwise
they seem to trip when building on non-OpenBSD platforms. The
Driver/linker test is updated to ensure lld is passed on this platform.
Note that OpenBSD calls "x86_64" as "amd64", so we use that name for the
architecture instead of trying to alias one to the other, as this makes
things simpler.
I still need to investigate the failures.
To unblock CI I'm disabling the verification for now.
Failing to correctly remangle a symbol should work, but failing so will not cause any severe damage (miscompile, etc.) in most cases.
rdar://problem/59813007
rdar://problem/59496022
https://bugs.swift.org/browse/SR-12204
