This is an error introduced as the result of a refactoring a while ago
and means that we will store dependently typed stored properties at the
wrong offset in a generic struct if it has stored properties of empty
types before said property.
rdar://36384871
If the 'self' type is abstract, we still have to consider it as
a source of type metadata, because it might be a class-bound
generic parameter and the class might have generic parameters.
Fixes <rdar://problem/36093833>.
We incorrectly lowered callsites when we had sil function return types
that involved both direct return types that we decide to lower
indirectly, and indirect return types.
@convention(thin) () -> (@owned String, @owned String, @owned String, @out Any, @out Any)
(This should have been handled by the address lowering pass but isn't)
rdar://35874410
Rather than silently returning "false" when we are unable to attempt
to satisfy a conditional conformance at runtime, produce a runtime
warning first, to note to users that this behavior is incorrect and
will change in the future.
Proper evaluation of conditional conformances at runtime (e.g., as part of
dynamic casting) is too large to tackle in the Swift 4.1 timeframe. For now,
record that a conformance is conditional in the protocol conformance record,
and always return "does not conform" to such types.
Fixes rdar://problem/35761301.
Fix collection subtyping relation in function argument position
by emiting special re-abstraction thunk with collection upcast.
Resolves: rdar://problem/35702810
Following up on the fixes for rdar://problem/35330067. If a class inherits a class from another module with missing fields, we need to treat its size and alignment as opaque, just like the base class itself. We also need to lay out such class at runtime, since we don't know the size, alignment, or field offsets at compile time; relying on the ObjC runtime alone will slide the ivar offsets, but not the Swift instance size and alignment. Fixes rdar://problem/35747485.
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
Since closure captures are now @guaranteed. Previous to this fix we
assumed @owned which matched the old closure capture convention.
Neither version is proper of course:
The proper fix, I will follow up with, is that when the large loadable
types pass lowers @guaranteed/@owned to @indirect_in_constant it should
disambiguate to @indirect_in_constant_guaranteed/owned.
rdar://35674625
Specifically, this is about the /version/ of the running OS.
Previously, this was only autodetected for the interpreter, with the
compiler defaulting to the earliest version of macOS supported by
Swift (10.9); picking the current running OS seems more useful. LLVM
changed their default behavior recently, so this doesn't actually
require any implementation changes.
This only affects macOS today, because it only affects compiling
without an explicit target (i.e. not cross-compiling) on an OS with
cross-version binary compatibility (i.e. not Linux).
rdar://problem/29948658
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
We would miscompile in mixed-language-version projects when a Swift class was compiled for one language version, while using Objective-C-imported types that are only available to that version, and then imported into a Swift module with a different language version that wasn't able to see all of the properties because of incompatible imported types. This manifested in a number of ways:
- We assumed we could re-derive the constant field offsets of the class's ivars from the layout, which is wrong if properties are missing, causing accesses to final properties or subclass properties to go to the wrong offsets.
- We assumed we could re-derive the instance size and alignment of a class instance in total, causing code to allocate the wrong amount of memory.
- We neglected to account for the space that stored properties take up in the field offset vector of the class object, causing us to load vtable entries for following subclass methods from the wrong offsets.
Eventually, resilience should reduce our exposure to these kinds of problems. As an incremental step in the right direction, when we look at a class from another module in IRGen, treat it as always variably-sized, so we don't try to hardcode offsets, size, or alignment of its instances. When we import a class, and we're unable to import a stored property, leave behind a new kind of MissingMemberDecl that records the number of field offset vector slots it will take up, so that we lay out subclass objects and compute vtable offsets correctly. Fixes rdar://problem/35330067.
A side effect of this is that the RemoteAST library is no longer able to provide fixed field offsets for class ivars. This doesn't appear to impact the lldb test suite, and they will ultimately need to use more abstract access patterns to get ivar offsets from resilient classes (if they aren't already), so I just removed the RemoteAST test cases that tested for class field offsets for now.
Partially reverts f4f8349 (from July!) which caused us to start
importing global blocks with unbridged parameters, breaking source
compatibility. I'm still investigating whether there's an actual hole
in the logic; see next few commits.
rdar://problem/34913634
Use the modern spelling for the nullability attributes in the test mock
headers. Currently, this was relying on the predefined macros from
clang to work. However, those are only available on Darwin targets.
This is needed to make the mock environments more portable.
