Add ability to automatically chaining the bridging headers discovered from all
dependencies module when doing swift caching build. This will eliminate all
implicit bridging header imports from the build and make the bridging header
importing behavior much more reliable, while keep the compatibility at maximum.
For example, if the current module A depends on module B and C, and both B and
C are binary modules that uses bridging header, when building module A,
dependency scanner will construct a new header that chains three bridging
headers together with the option to build a PCH from it. This will make all
importing errors more obvious while improving the performance.
* Move `AvailabilitySpec` handling logic to AST, so they can be shared
between libParse and ASTGen
* Requestify '-define-availability' arguments parsing and parse them
with 'SwiftParser' according to the 'ParserASTGen' feature flag
* Implement 'AvailableAttr' generation in ASTGen
RuntimeVersions.def.
This really *ought* to be NFC, but alas, there are two behavior changes.
The first is that arbitrary future versions (short of the special future
version of 99.99) used to be considered to be free of all deployment
issues, but are now just considered to offer the Swift release that's
attached to the last known release of the target platform. The old behavior
was fine in a sense: deployment issues require updating the compiler anyway,
so if you haven't taught the compiler that iOS 31 provides Swift 8.3, you
probably also haven't taught it about any problems that are fixed in
Swift 8.3. The only problem with this logic is that we often implement
compiler fixes for these deployment issues before that first OS actually
ships (and thus before we've settled on a release number), and so we end
up with a race where we start considering new releases to fix the issue
even without updating the release mapping. The new approach fixes this:
we say that the bug will be fixed in Swift 8.3, and for the time being,
there are simply no platforms that provide that fix yet. Later, we update
the mapping to say that iOS 31 provides it, and compilations targeting that
release will be able to take advantage.
The other issue is that we actually treated "future" releases of macOS 10.x
(starting with 10.16, which ended up being 11.0) the same way, instead of
treating them logically as intermediate between 10.15 and 11.0.
My initial attempt at this generation used a constexpr array of a struct
with a std::initializer_list of platform releases, exactly mirroring the
structure of the .def file and requiring the compiler to parse out the
bits relevant to the target dynamically. The approach I ended up with is
much better, but I was actually forced into it because MSVC miscompiled
those global "temporary" arrays --- they ended up uninitialized.
We're using C++ 14+ at least now across the project so these should not be necessary. It's also kind of wild that the definitions we had across different subsystems had different definitions.
While here, also sort and deduplicate output entries, and stop having
the Python script try to
The Python script is still messing up the files in some cases, but
I haven't tracked it down. Instead, I have a small Swift program
that does the same thing more easily.
The symbol graph output from a module can contain an arbitrary number of
files, depending on what extensions it contains, so cache a list of
symbol graph files with their base name and contents so that they can be
replayed.
rdar://140286819
CAS support in compiler relies on supplementary paths to decide the mapping between input and output files. Therefore, we
have to compute the paths of the module ObjC trace files in this canonical place to have CAS support for
this newly added ObjC message trace files.
At the moment the only user of this method is `-interface-compiler-version`
and it's checked against major + minor only, so this is not going
to affect functionality.
In the future we should switch from `llvm::VersionTuple` to `swift::Version`
because swift tags have five components.
Resolves: rdar://140006577
Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
This is something that I have wanted to add for a while and have never had the
need to. I need it now to fix a bug in the bots where I am forced to use IRGen
output to test ThunkLowering which causes platform level differences to show up
in the FileCheck output. With this, I can just emit the actual lowered SIL
output and just test it at that level. There are other cases like this where we
are unable to test lowered SIL so we use IRGen creating this brittleness.
Hopefully this stops this problem from showing up in the future.
rdar://138845396
to verify ExportedSourceFileRequest == 0.
In release mode only non-zero stats are printed by default now.
Fix diagnostic when compiler is built without statistics support.
BlockListStore doesn't need to keep the buffer after the block-list is
parsed. Don't share the same source manager as the compilation so it
doesn't need to make sure the buffer is valid during the entire duration
of the compilation.
rdar://137448231
Add a new filetype for this mode option: "Raw LLVM IR". When the mode
option is emit-irgen, the new filetype will be the output kind;
conversely when determining the mode option to use, if the output kind
is the new filetype, the mode option will be emit-irgen.
Make sure block-list file is read through VFS so CASFS can be used to
read the configuration to ensure sound caching, and also the path of the
blocklist can be canonicalized via path remapping.
Now that every source file has a buffer ID, introduce the reverse mapping
so clients can find the source file(s) in their module that reference
that buffer ID.
