This change adds a frontend flag, -verify-additional-file, which can be used to pass extra files directly to the diagnostic verifier. These files are not otherwise considered to be Swift source files; they are not compiled or even properly parsed.
This feature can be used to verify diagnostics emitted in non-source files, such as in module interfaces or header files.
This doesn't really fit the request evaluator model since the
result of evaluating the request is the new insertion point,
but we don't have a way to get the insertion point of an
already-expanded scope.
Instead, let's change the callers of the now-removed
expandAndBeCurrentDetectingRecursion() to instead call
expandAndBeCurrent(), while checking first if the scope was
already expanded.
Also, set the expanded flag before calling expandSpecifically()
from inside expandAndBeCurrent(), to ensure that re-entrant
calls to expandAndBeCurrent() are flagged by the existing
assertion there.
Finally, replace a couple of existing counters, and the
now-gone request counter with a single ASTScopeExpansions
counter to track expansions.
Switch from a string core to a 128-bit integral core. This should make
Fingerprints much cheaper to copy around and sets us up for a future
where we can provide alternative implementations of the ambient hashing
algorithm.
rdar://72313506
Introducing new entry-points that can be used from both Driver and Frontend clients, using an intermediary new type: `DetailedMessagePayload`, when needed.
Starting at a crude -1000, each invocation primary input will get its own unique quasi-Pid.
Invocations with only one primary (non-batch) will get a real OS Pid.
The selection of the constant starting point matches what the driver does when outputting its parseable output.
We're going to play a dirty, dirty trick - but it'll make our users'
lives better in the end so stick with me here.
In order to build up an incremental compilation, we need two sources of
dependency information:
1) "Priors" - Swiftdeps with dependency information from the past
build(s)
2) "Posteriors" - Swiftdeps with dependencies from after we rebuild the
file or module or whatever
With normal swift files built in incremental mode, the priors are given by the
swiftdeps files which are generated parallel to a swift file and usually
placed in the build directory alongside the object files. Because we
have entries in the output file map, we can always know where these
swiftdeps files are. The priors are integrated by the driver and then
the build is scheduled. As the build runs and jobs complete, their
swiftdeps are reloaded and re-integrated. The resulting changes are then
traversed and more jobs are scheduled if necessary. These give us the
posteriors we desire.
A module flips this on its head. The swiftdeps information serialized
in a module functions as the *posterior* since the driver consuming the
module has no way of knowing how to rebuild the module, and because its
dependencies are, for all intents and purposes, fixed in time. The
missing piece of the puzzle is the priors. That is, we need some way of
knowing what the "past" interface of the module looked like so we can
compare it to the "present" interface. Moreover, we need to always know
where to look for these priors.
We solve this problem by serializing a file alongside the build record:
the "external" build record. This is given by a... creative encoding
of multiple source file dependency graphs into a single source file
dependency graph. The rough structure of this is:
SourceFile => interface <BUILD_RECORD>.external
| - Incremental External Dependency => interface <MODULE_1>.swiftmodule
| | - <dependency> ...
| | - <dependency> ...
| | - <dependency> ...
| - Incremental External Dependency => interface <MODULE_2>.swiftmodule
| | - <dependency> ...
| | - <dependency> ...
| - Incremental External Dependency => interface <MODULE_3>.swiftmodule
| - ...
Sorta, `cat`'ing a bunch of source file dependency graphs together but
with incremental external dependency nodes acting as glue.
Now for the trick:
We have to unpack this structure and integrate it to get our priors.
This is easy. The tricky bit comes in integrate itself. Because the
top-level source file node points directly at the external build record,
not the original swift modules that defined these dependency nodes, we
swap the key it wants to use (the external build record) for the
incremental external dependency acting as the "parent" of the dependency
node. We do this by following the arc we carefully laid down in the
structure above.
For rdar://69595010
Goes a long way towards rdar://48955139, rdar://64238133
Previously FieldIndexCacheBase only had a parent class of
SingleValueInstruction. I need to be able to in certain cases shim in a
SingleValueInstruction subclass as a parent class instead. In my case it is to
imbue ownership forwarding on StructExtractInst.
This commit itself doesn't make that change and instead just always templatizes
using SingleValueInstruction.
Passing the frontend flag -Rmodule-loading makes the compiler emit
remarks with the path of every module loaded. The path for Swift modules
is either the swiftinterface file for modules built with library
evolution or the binary swiftmodule otherwise. The path for clangmodules
is always in the cache which could be improved as it may be less useful.
Here's an extract of the output for a simple SwiftUI app:
<unknown>:0: remark: loaded module from
/Users/xymus/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2VJP7CNCGWRF0/SwiftShims-18ZF6992O9H75.pcm
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/usr/lib/swift/Swift.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
<unknown>:0: remark: loaded module from
/Users/xymus/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2VJP7CNCGWRF0/os-1HVC6DNXVU37C.pcm
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/usr/lib/swift/os.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
MSVC2017 seems to not fallback to the correct overloaded constructor
when an initializer list constructor seems to be used, but only fails
because the conversion rules. Using parenthesis instead of braces seems
to indicate MSVC2017 the right constructor to use, and should work in
the rest of the compilers as well.
Seems that MSVC2019 is more resilient to this ambiguity.
Introduced in #34808 and started failing https://ci-external.swift.org/job/oss-swift-windows-x86_64/5953/
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 frontend flag can be used as an alternative to
-experimental-skip-non-inlinable-function-bodies that doesn’t skip
functions defining nested types. We want to keep these types as they are
used by LLDB. Other functions ares safe to skip parsing and
type-checking.
rdar://71130519
Adds a new frontend option
"-experimental-allow-module-with-compiler-errors". If any compilation
errors occur while generating the .swiftmodule, this mode will skip SIL
entirely and only serialize the (likey invalid) AST.
This existence of this option during generation is serialized into the
resulting .swiftmodule. Errors found in deserialization are only allowed
if it is set.
Primarily intended for IDE requests (eg. indexing and code completion)
to ensure robust cross-module results, despite possible errors.
Resolves rdar://69815975
Adds a new flag "-experimental-skip-all-function-bodies" that skips
typechecking and SIL generation for all function bodies (where
possible).
`didSet` functions are still typechecked and have SIL generated as their
body is checked for the `oldValue` parameter, but are not serialized.
Parsing will generally be skipped as well, but this isn't necessarily
the case since other flags (eg. "-verify-syntax-tree") may force delayed
parsing off.
