Use begin_unpaired_access [no_nested_conflict] for
Builtin.performInstantaneousReadAccess. This can't be optimized away
and is the proper marker to use when the access scope is unknown.
Drop the requirement that
_semantics("optimize.sil.preserve_exclusivity") be @inline(never). We
actually want theses inlined into user code. Verify that the
@_semantic functions are not inlined or otherwise tampered with prior
to serialization.
Make *no* change to propagate @inline(__always) into LLVM. This no longer has
any relationship to this PR and can be investigated seperately.
Add dynamic enforcement of exclusive access when a KeyPath directly accesses a final
stored property on an instance of a class. For read-only projections, this begins and ends
the access immediately. For mutable projections, this uses the ClassHolder to perform
a long-term access that lasts as long as the lifetime of the ClassHolder.
rdar://problem/31972680
Type of elements contained by field offsets vector can be adjusted
to 32-bit integers (from being pointer sized) to safe space in the
binary since segment size is limited to 4 GB.
Resolves: rdar://problem/36560486
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
Include the initial implementation of _StringGuts, a 2-word
replacement for _LegacyStringCore. 64-bit Darwin supported, 32-bit and
Linux support in subsequent commits.
When we pre-scan the components of a key path pattern to determine its runtime type and instance size, we would short-circuit upon seeing an optional-chaining component, since that makes a key path definitely read-only, but the loop also accumulates the size of the instance we're supposed to allocate, so…bad stuff happened. Leave out the short-circuit, fixing SR-6096 | rdar://problem/34889333 .
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
- Revisions to unsafeDowncast and withVaList
- Fix the Int64/UInt64 discussion
- Buffer pointer revisions
- Fix Optional example to use new integer methods
- Revise and correct some UnsafeRawBufferPointer docs
- Fix symmetricDifference examples
- Fix wording in FloatingPoint.nextDown
- Update ImplicitlyUnwrappedOptional
- Clarify elementsEqual
- Minor integer doc fixes
- Comment for _AppendKeyPath
- Clarification re collection indices
- Revise RangeExpression.relative(to:)
- Codable revisions
In the type checker, we need to recognize when a member lookup succeeded through an IUO unwrap, and insert the implicit optional-unwrap component into the key path. In the standard library, we need to cope with the fact that IUO is still a first-class type with unique type metadata in a few places. Fix for rdar://problem/33230845.
Using an Array to hold onto all the cleanup objects for an access happens to destroy the cleanup objects in FIFO order (and it's probably not a good idea to rely on Array cleaning itself up in any particular order at all). For want of proper accessor coroutines, chain the cleanup objects in a linked list so that they reliably get destroyed in the desired inside-out order. Fixes SR-5442 | rdar://problem/33267959.
A necessary precursor to supporting subscripts and unspecialized generic accessors in general. Give get/set components the ability to have an "argument" area that gets instantiated by copying out of the key path pattern arguments at instantiation time, and which holds "witness" information for how to copy, destroy, equate, and hash arguments.
To get the full benefit of dyld3 on Darwin platforms, pointer relocations need to be pointer-aligned, which unfortunately requires growing some key path data structures a little bit. This does tidy up some code that had to hack around our lack of unaligned load/store operations on UnsafeRawPointer, at least. While we're here, we can also simplify the identification strategy for reabstracted stored properties; we only need the property index to identify, not the absolute offset. rdar://problem/32318829
We need to use the ivar offset variables in this case, since the Swift field offset vector doesn't pick up the adjusted offsets from the ObjC runtime. Fixes SR-5036 | rdar://problem/32488871.
- remove additional 'characters' references from String docs
- improved language around escaping pointer arguments
- key path type abstracts
- codable type abstract revisions
- a few more NSString API fixes
A property imported from Objective-C, or marked in Swift with the `dynamic` keyword, doesn't have a vtable slot, so can't be identified that way. Use the ObjC selector as the unique identifier to ascribe equality to such components. Fixes rdar://problem/31768669. (While we're here, throw some more execution tests and a changelog note in.)
I had optimistically written the code here optimistically hoping #7837 would land in time for me to merge, but that didn't happen, so adjust some things to match the current 12-byte object header size on 32-bit, and introduce some ABI constants for the expected 32- and 64-bit object header sizes we can assert against so that we have some robustness when it eventually changes again. Implements rdar://problem/31768303.
