When we are printing Swift interface, we have to skip the override keyword
if the overriden decl is invisible from the interface. Otherwise, an error
will occur while building the Swift module because the overriding decl
doesn't override anything.
We couldn't skip every `override` keywords because they change the
ABI if the overriden decl is also publicly visible.
For public-override-internal case, having `override` doesn't have ABI
implication. Thus we can skip them.
rdar://58562780
Protocol conformances can be implied by super classes. When collecting the list
of IncludedProtocols, we should traverse the class inheritance chain and collect
all protocols.
Without this change, these implied conformances will be printed again via a synthesized
extension at the end of the Swift interface file, leading to an error of redundant
conformances when building modules.
rdar://58563540
Currently, when a swiftinterface file fails to load, we emit the specific diagnostics for the failures, followed by a generic “failed to load module ‘Foo’” message. This PR improves that final diagnostic, particularly when the cause may be that the interface was emitted by a newer compiler using backwards-incompatible syntax.
The only initialization these class objects need is ObjC realization, which can be done
fast with `objc_opt_self` on recent Apple OSes. The cache check just adds code size and
dirties memory.
The test uses %target-run, which requires executing code. Android CI
cannot execute code because no device is attached. Marking the test as
executable skip it in the Android CI machines.
This test fails sometimes with something like:
SOURCE_DIR/test/ModuleInterface/ModuleCache/prebuilt-module-cache-forwarding.swift:47:8: error: malformed compiled module: BUILD_DIR/test-macosx-x86_64/ModuleInterface/ModuleCache/Output/prebuilt-module-cache-forwarding.swift.tmp/MCP/Lib-2XZQCTV44N470.swiftmodule
rdar://58578342
Manually expand out the few places where we had a `not ...` substitution
where the substituted value was invoking `env` to alter the environment.
This pattern is not portable and causes problems when using the
integrated shell, such as on Windows. This was identified during the
LLVM update.
This additionally corrects the use of `not` to indicate that it is
expecting a crashing failure. This was resulting in the Windows tests
failing as `not` was not expecting a crashing failure.
The check for whether or not we can use a function builder on a property
checked whether the attached getter had a body, which is not always true for
module interfaces. Just disable that part of the check when compiling a
module interface.
rdar://58535753
This reverts commit e805fe486e, which reverted
the change earlier. The problem was caused due to a simultaneous change to some
code by the PR with parsing and printing for Clang function types (#28737)
and the PR which introduced Located<T> (#28643).
This commit also includes a small change to make sure the intersecting region
is fixed: the change is limited to using the fields of Located<T> in the
`tryParseClangType` lambda.
This change ensures using .swiftmodule built from source has the same behavior as
using .swiftmodule built from .swiftinterface.
A swift-ide-test utility is added to print linked libraries from a Swift module for
testing purposes.
rdar://58057556
We need this attribute to teach compiler to use a different name from the current
module name when generating runtime symbol names for a declaration. This is to serve
the workflow of refactoring a symbol from one library to another without breaking the existing
ABI.
This patch focuses on parsing and serializing the attribute, so @_originallyDefinedIn
will show up in AST, swiftinterface files and swiftmodule files.
rdar://55268186
Previously, we would print
```swift
public private(set) var x: Int
```
as
```swift
@_hasStorage public var x: Swift.Int {
get
}
```
which is a) incorrectly indented, and b) shouldn't have newlines in part
of the Generated Interface.
Fixes [SR-9816](https://bugs.swift.org/browse/SR-9816)
Windows paths attack again. Some paths from the dependency tracker have
mixed folder separators, so comparing textually fail. Additionally some
paths seems to be extended paths (\\?\) which seems not to be liked by
LLVM path utilities.