We use the just-built clang without any -target or -sdk flags. Keep things
simple and limit the test to macOS for now.
Fixes <rdar://problem/50586614>.
Without -enable-resilient-objc-class-stubs, don't print classes with
resilient ancestry at all, since they're not actually visible to
Clang and referencing one will not actually work.
When the flag is specified, such classes do appear in the generated
header with the new objc_class_stub Clang attribute.
I also removed the -verify-sil-ownership flag in favor of a disable flag
-disable-sil-ownership-verifier. I used this on only two tests that still need
work to get them to pass with ownership, but whose problems are well understood,
small corner cases. I am going to fix them in follow on commits. I detail them
below:
1. SILOptimizer/definite_init_inout_super_init.swift. This is a test case where
DI is supposed to error. The only problem is that we crash before we error since
the code emitting by SILGen to trigger this error does not pass ownership
invariants. I have spoken with JoeG about this and he suggested that I fix this
earlier in the compiler. Since we do not run the ownership verifier without
asserts enabled, this should not affect compiler users. Given that it has
triggered DI errors previously I think it is safe to disable ownership here.
2. PrintAsObjC/extensions.swift. In this case, the signature generated by type
lowering for one of the thunks here uses an unsafe +0 return value instead of
doing an autorelease return. The ownership checker rightly flags this leak. This
is going to require either an AST level change or a change to TypeLowering. I
think it is safe to turn this off since it is such a corner case that it was
found by a test that has nothing to do with it.
rdar://43398898
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
If the block is guaranteed, we need to be sure to copy here. This can happen for
instance with arguments (where this was caught). I added a SILGen test that
exposes this failure since this is not an actual bug in PrintAsObjC.
This is a new warning in clang when you use @import in a framework header. That’s often a mistake, but it isn’t in our generated -Swift.h headers. If we’re building with a clang that supports this warning, we’ll now emit a pragma to disable it.
These handle imported types that have been renamed in a /later/ Swift
version than the one being used; for consistency when deserializing
from a swiftmodule, the latest name is always used. This is important
because it might mean we can avoid importing the framework that a name
comes from; a forward declaration might be sufficient if it's an ObjC
class or protocol.
rdar://problem/45491607
* Introduce stored inlinable function bodies
* Remove serialization changes
* [InterfaceGen] Print inlinable function bodies
* Clean up a little bit and add test
* Undo changes to InlinableText
* Add serialization and deserialization for inlinable body text
* Allow parser to parse accessor bodies in interfaces
* Fix some tests
* Fix remaining tests
* Add tests for usableFromInline decls
* Add comments
* Clean up function body printing throughout
* Add tests for subscripts
* Remove comment about subscript inlinable text
* Address some comments
* Handle lack of @objc on Linux
The ObjC generator previously preserved a subtle difference between
'unowned' and 'unowned(unsafe)' / Unmanaged by printing the former as
'assign' and the latter as 'unsafe_unretained'. Upstream Clang,
however, has gotten a new warning to discourage the use of 'assign'
with reference-countable types at all. Since it was always a subtle
distinction, just go with the new convention and print
'unsafe_unretained' for 'unowned' properties as well.
rdar://problem/44290715
(either explicitly generic ones, or those embedded in generic contexts)
Previously we tried to look at the typealias decl's underlying type,
but that might have generic parameters in it. Oops. Use the
NameAliasType's desugared type instead.
Also, drop half-baked support for `@objc typealias`, which isn't
supported. (It's not an unreasonable feature, but the bits that were
there weren't implemented correctly.)
rdar://problem/43347303
Previously they were ignored by the checking of '@objc', but in the
refactoring to a request the attribute started getting marked as
invalid without a diagnostic.
rdar://problem/43401047
Technically, these operations belong in the ObjectiveC module, where NSObject
is defined. Keep them there. However, we need to build the mock ObjectiveC
overlay with `-disable-objc-attr-requires-foundation-module` now.
