Fix use-after-free in helper function `printSILFunctionNameAndType`.
The address of a `DenseMap` local variable is used after the function returns.
Resolves SR-12239.
Instead of interleaving typechecking and parsing
for SIL files, first parse the file for Swift
decls by skipping over any intermixed SIL decls.
Then we can perform type checking, and finally SIL
parsing where we now skip over Swift decls.
This is an intermediate step to requestifying the
parsing of a source file for its Swift decls.
Otherwise certain modules don't import correctly when built against an
Apple-internal SDK. Should have no effect when using the public SDK,
but we try to minimize divergence between the public and
Apple-internal test suites.
rdar://problem/48513002
This turns out to be the only problem on iOS and tvOS. Oops! macOS
still has some actual failing overlays as tracked by SR-9847.
(We should also add this search path to
ParseableInterface/verify_all_overlays.py.)
rdar://problem/48458622
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
Tracked within Apple by <rdar://problem/36754225> Swift CI:
parse_stdlib.sil tests failing with vtable verification. The error is
an assertion failure that we haven't traced back to its cause yet:
Assertion failed: (EntriesSZ == VTableEntryCache.size() && "Cache
size is not equal to true number of VTable entries"), function
verify, file /Users/buildnode/jenkins/workspace/
oss-swift-package-osx/swift/lib/SIL/SILVerifier.cpp, line 4747.
Being part of the type of a private declaration isn't sufficient,
because that could be used for the inferred type of a non-private
variable/constant/property.
Also, introduce a new kind of dependency test that shows both that a
file A changes its interface based on a change in another file B, and
that the swiftdeps output for file A includes the dependency on file B
as cascading.
https://bugs.swift.org/browse/SR-6149
The sharding of this test buys us nothing, because it was only sharding
the AST verifier, which is an insignificant portion of the runtime
(and memory usage) of this test. Given that the test takes ~2m30s to run
and consumes > 2GB memory, having 17 copies of it running is a problem.
The test was originally disabled but to timeouts that were supposedly caused by the new integer protocols. A few improvements have been implemented in the compiler as well as in the standard library since them, so it might no longer be a problem.
introduce a common superclass, SILNode.
This is in preparation for allowing instructions to have multiple
results. It is also a somewhat more elegant representation for
instructions that have zero results. Instructions that are known
to have exactly one result inherit from a class, SingleValueInstruction,
that subclasses both ValueBase and SILInstruction. Some care must be
taken when working with SILNode pointers and testing for equality;
please see the comment on SILNode for more information.
A number of SIL passes needed to be updated in order to handle this
new distinction between SIL values and SIL instructions.
Note that the SIL parser is now stricter about not trying to assign
a result value from an instruction (like 'return' or 'strong_retain')
that does not produce any.
I don't have reduced test cases. The original test cases
were a series of frontend invocations in -parse-stdlib
mode.
While the original bugs seem to have been fixed, while
verifying I found a few places where we weren't checking
for null decls property in the ASTContext.
Probably not too useful to check this in, but I don't see it
causing any harm, either.
All we need to store is whether the SILDeclRef directly
references the declaration, or if it references a curry
thunk, and we already have an isCurried bit for that.
With more recent versions of LLVM (e.g., used with master-next) the
argument of REQUIRES is parsed as an expression. Do not use "rdar"
URLS for these since it confuses lit.
Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
The existence of a shared_external function in itself is not
an error; it just means we deserialized a witness table or
vtable but did not need to deserialize a thunk.
However, a direct reference to such a function is an error,
because we should have deserialized the body in that case.
This fixes a crasher, but the SIL crashers are kind of silly
because the SIL parser does not try at all not to crash on
invalid input.
Also, add a third [serializable] state for functions whose bodies we
*can* serialize, but only do so if they're referenced from another
serialized function.
This will be used for bodies synthesized for imported definitions,
such as init(rawValue:), etc, and various thunks, but for now this
change is NFC.
Currently if destination is unresolved instead of trying to re-typecheck
it again and diagnose structural problems which led to such outcome, it
gets completely ignored in favor of trying to type-check source without
contextual type. That leads to missed diagnostic opportunities, which
results in problems on AST verification and SIL generation stages, and
generally missleading errors e.g. `.x = 0`.
Resolves: SR-3506.
