This failure will most-likely result in the dependency query failure which will fail the scan. It will be helpful if the scanner emitted diagnostic for each such module it rejected to explain the reason why.
Resolves rdar://142906530
When building the runtime we define `SWIFT_RUNTIME`. `swiftCore_EXPORTS`
is only defined when building swiftCore as a shared library. This would
thus allow the ODR violations to appear in a static library form of the
standard library. This was uncovered with the new runtime build system.
Since availability scopes may be built at arbitrary times, the builder may
encounter ASTs where SequenceExprs still exist and have not been folded, or it
may encounter folded SequenceExprs that have not been removed from the AST.
To avoid a double visit, track whether a SequenceExpr is folded and then
customize how ASTVisitor handles folded sequences.
Resolves rdar://142824799 and https://github.com/swiftlang/swift/issues/78567.
We're not planning on removing the splitter because it is a big win
in some cases, but we want to run it less often since it can also
be a source of overhead. This flag allows us to compare performance
to understand the tradeoffs better.
Parsing for `-enable-upcoming-feature` and `-enable-experimental-feature` is
lenient by default because some projects need to be compatible with multiple
language versions and compiler toolchains simultaneously, and strict
diagnostics would be a nuisance. On the other hand, though, it would be useful
to get feedback from the compiler when you attempt to enable a feature that
doesn't exist. This change splits the difference by introducing new diagnostics
for potential feature enablement misconfigurations but leaves those diagnostics
ignored by default. Projects that wish to use them can specify `-Wwarning
StrictLanguageFeatures`.
Diagnostics may be emitted while parsing command line arguments. This implies
that the options which affect how diagnostics are emitted and presented need to
be parsed first.
This adjusts the runtime function declaration handling to track the
owning module for the well known functions. This allows us to ensure
that we are able to properly identify if the symbol should be imported
or not when building the shared libraries. This will require a
subsequent tweak to allow for checking for static library linkage to
ensure that we do not mark the symbol as DLLImport when doing static
linking.
Expose a `Task`'s resume context via the `AsyncTaskInfo` struct.
This will be used by lldb, but since this data is not specific to lldb it seems reasonable to include it generally.
Diagnostics are suppressed when parsing swiftinterface files, since the
warnings emitted from compiling the swiftinterface of a dependency would just
be a nuisance. It follows that warnings generated when parsing the arguments in
a swiftinterface file should also be suppressed, but that wasn't happening
because the diagnostic engine of the main compile was used for parsing. Pass
the diagnostic engine of the compiler subinstance instead, and proactively
suppress warnings before parsing begins.
Resolves rdar://142814164.
The issue here is that the demangler (since we have a postfix mangling) parses
parameters/results/etc and then uses earlier postfix type arguments to attach
the relevant types to the parameters/results/etc. Since the flag for a sending
result was placed in between the parameters and results, we get an off by one
error.
Rather than fix that specific issue by introducing an offset for the off by one
error, I used the fact that the impl-function part of the mangling is not ABI
and can be modified to move the bit used to signify a sending result to before
the parameters so the whole problem is avoided.
I also while I was doing this looked through the sending result mangling for any
further issues and fixed them as I found them.
rdar://141962865
I discovered this while trying to figure out why we were dropping a sending bit
when computing a reabstraction thunk in the tests for the following commit. This
turned out to be the reason why.
Now that AvailableAttr has storage for its cached AvailabilityDomain, it's no
longer necessary to store an AvailabilityDomain inline in
SemanticAvailableAttr.
NFC.
`x declared here` is not helpful and clear enough, especially when there
are other notes attached. Swap it for a new note that says
`requirement x declared here`.
Represent an AvailabilityDomain as a pointer union where one member of the
union is inline storage for built-in domains with known requirements and the
other member of the union is a pointer to an externally allocated domain
definition.
NFC.
Types annotated as `@_addressableForDependencies` are still usable by older
compilers that don't know about nonescapable types or lifetime dependencies,
since it only affects the behavior of the type when it's the source of a
dependency.
This diagnostic was staged in
https://github.com/swiftlang/swift/pull/38991 as a warning to not break
source. Give it a reasonable margin and, in turn, convey that it is in
fact a compatibility warning and will become an error.
