"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
Remove the cast consumption kind from all unconditional casts. It
doesn't make sense for unconditional casts, complicates SIL ownership,
and wasn't fully supported for all variants. Copies should be
explicit.
In dead-array elimination we assume that the array allocation is post-dominated by all its final releases.
The only exception are branches to dead-end ("unreachable") blocks. So we just ignored all paths which didn't end up in a final release.
Now we explicitly pass the set of dead-end blocks and just ignore those blocks.
This is safer and it's also needed in the upcoming re-write of StackPromotion.
partial_apply is a confusing instruction since it:
1. Is printed with a function signature.
2. Takes in some arguments of the same type as the underlying types of the given function signatures.
3. Always takes in those arguments at +1 regardless of the convention printed on the partial apply.
Eventually we will split the partial apply representation so that the box is
represnted explicitly separately from the function signature, eliminating this
confusion.
The problem that we ran into here is that we were not treating @in values from
an alloc_stack or @in_guaranteed at all correctly. The reason why the tests did
not catch this is that a seperate sil_combine optimization that eliminates
trivially dead live ranges was eliminting the alloc_stack of the @in value in
our test. In contrast, the @in_guaranteed case was actually never tested at all.
I added tests for all of these conventions and in addition added a special mode
to SILCombine that stops the alloc_stack eliminating during testing.
rdar://32887993
This peephole is to avoid runtime calls:
unconditional_checked_cast_addr T in %0 : $*T to P in %1 : $*P
->
%addr = init_existential_addr %1 : $*P, T
copy_addr %0 to %addr
where T is a type statically known to conform to non-class existential P.
In caase P is a class existential type, it generates:
%val = load %0 : $*T
%existential = init_existential_ref %val : $T, $T, P
store %existential to %1 : $*P
If there is a conditional bridged cast from a swift type to an objc type and this cast happens in two stages, where:
- in the firs stage the Swift type is casted to its bridged ObjC class (e.g. String to NSString) and
- in the second stage there is a downcast to a subclass of a bridged ObjC class (e.g. NSString to MyString)
then the second stage should use a conditional cast.
rdar://32319580
When casting from an object type to a bridged Swift value type, classifyDynamicCast would use the cast classification for the target type's bridged object type, which would be trivially WillSucceed for thinks like NSNumber-to-Int or NSError-to-SomeError, even though the bridging itself could fail. Fixing this fixes SR-2920|rdar://problem/31404281.
If the concrete type is an existential or a generic type, we should not perform the optimization, because we don’t know enough information about it.
Fixes rdar://31372306
Till now createApply, createTryApply, createPartialApply were taking some arguments like SubstCalleeType or ResultType. But these arguments are redundant and can be easily derived from other arguments of these functions. There is no need to put the burden of their computation on the clients of these APIs.
The removal of these redundant parameters simplifies the APIs and reduces the possibility of providing mismatched types by clients, which often happened in the past.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This bug occurs in real projects, when type aliases are involved.
The test-case is a bit hard to provide. I’ll try to provide it later, if I managed to reduce the original project to a small test-case.
But the fix is very obvious.
Fixes rdar://31768258
With -sil-serialize-all, we might deserialize and specialize
a private function from multiple TUs which are then linked
together.
Since private symbols have unique mangling, this is fine.
It's hard to make a test for this since it only happens with
-sil-serialize-all, which I'd like to kill soon anyway.
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.
Change emitApplyOfLibraryIntrinsic() to take a SubstitutionMap,
and use the correct abstractions to build the map.
This gets rid of the last remaining uses of gatherAllSubstitutions()
in SIL.
