* Reimplement most of the logic in Swift as an Instruction simplification and remove the old code from SILCombine
* support more cases of existential archetype replacements:
For example:
```
%0 = alloc_stack $any P
%1 = init_existential_addr %0, $T
use %1
```
is transformed to
```
%0 = alloc_stack $T
use %0
```
Also, if the alloc_stack is already an opened existential and the concrete type is known,
replace it as well:
```
%0 = metatype $@thick T.Type
%1 = init_existential_metatype %0, $@thick any P.Type
%2 = open_existential_metatype %1 : $@thick any P.Type to $@thick (@opened("X", P) Self).Type
...
%3 = alloc_stack $@opened("X", any P) Self
use %3
```
is transformed to
```
...
%3 = alloc_stack $T
use %3
```
If an apply uses an existential archetype (`@opened("...")`) and the concrete type is known, replace the existential archetype with the concrete type
1. in the apply's substitution map
2. in the arguments, e.g. by inserting address casts
For example:
```
%5 = apply %1<@opend("...")>(%2) : <τ_0_0> (τ_0_0) -> ()
```
->
```
%4 = unchecked_addr_cast %2 to $*ConcreteType
%5 = apply %1<ConcreteType>(%4) : <τ_0_0> (τ_0_0) -> ()
```
* factor out common methods of AST Type/CanonicalType into a `TypeProperties` protocol.
* add more APIs to AST Type/CanoncialType.
* move `MetatypeRepresentation` from SIL.Type to AST.Type and implement it with a swift enum.
* let `Builder.createMetatype` get a CanonicalType as instance type, because the instance type must not be a lowered type.
Replace `unconditional_checked_cast` to an existential metatype with an `init_existential_metatype`, it the source is a conforming type.
Note that init_existential_metatype is better than unconditional_checked_cast because it does not need to do any runtime casting.
So far a `SILCombineSimplifiable` could only replace a SILCombine visit implementation.
With the `SWIFT_SILCOMBINE_PASS_WITH_LEGACY` (to be used in Passes.def) it's possible to keep an existing C++ implementation and on top of that add a Swift Simplification pass.
The optional C++ type was bridged to a non-optional Swift type.
The correct way is to bridged the non-optional C++ type to the non-optional Swift type.
* getting the formal source and target types of casts
* `isFromVarDecl` and `usesMoveableValueDebugInfo` for AllocStackInst
* WitnessMethod APIs
* `TryApply.isNonAsync`
Check if an operand's instruction has been deleted in `UseList.next()`.
This allows to delete an instruction, which has two uses of a value, during use-list iteration.
Don't include type-dependent operands in the argument list of the new keypath instruction.
Also enable the assert, which catches this problem, in release builds.
Fixes a compiler crash.
This is really old code from before llvm::hash_combine existed. We really
shouldn't be rolling out own hash combine when we have something that we are
consistently using from LLVM. I validated the history of this code and talked
with JoeG/DougG/others to see if there was any reason beyond not having
hash_combine for us not to use hash_combine.
The reason why I am changing this now is that I want to convert SILDeclRef to
have another additional bit and use an OptionSet. When I noticed this... my eyes
burned, so I thought I would just quickly fix it before I landed the other
change so it could be a NFC change.
Introduction, deprecation, and obsoleteion ranges should only be returned by
the accessors on `SemanticAvailableAttr` when the attribute actually has an
affect on the corresponding kind of availability.
`AvailabilityRange` is now being used as a currency type in more of the
compiler, and some of those uses are in permanent `ASTContext` allocations. The
class wraps the `VersionRange` utility, which is itself a wrapper around
`llvm::VersionTuple` with some additional storage for representing sentinel
values. Even though the two sentinel values can be be represented with just a
single bit of additional storage on top of the 16 bytes required to represent
`VersionTuple`, because of alignment requirements the sentinel values end up
bloating the layout of `VersionRange` by many bytes.
To make `AvailabilityRange` and `VersionRange` more efficient to store, we can
instead reserve two unlikely `llvm::VersionTuple` bit patterns as the sentinel
values instead. The values chosen are the same ones LLVM uses to represent
version tuple tombstones and empty keys in a `DenseMap`.
Determining a descriptor's size requires reading its contents, but reading its contents from out of process requires knowing its size.
Build up the size incrementally by walking over the TrailingObjects. Take advantage of the fact that each trailing object's presence/count depends only on data that comes before it. This allows us to read prefixes that we gradually expand until we've covered the whole thing.
Add calls to TrailingObjects to allow iterating over the prefix sizes, and modify readContextDescriptor to use them. This replaces the old code which attempted to determine the descriptor size in an ad-hoc fashion that didn't always get it right.
rdar://146006006
Introduce a constructor that takes an `llvm::VersionTuple` directly, instead of
needing to spell out `VersionRange::allGTE(<tuple>)` which is unnecessarily
verbose.
Introduced `SemanticAvailabilitySpecRequest` to retrieve the semantic spec for
an `AvailabilitySpec`. Add an `isInvalid` bit to `AvailabilitySpec` to track
whether the request failed. Unfortunately, there aren't any easily accessible
spare bits in the layout of `AvailabilitySpec` so it had to be a new field.
For the options that specifies the output, it should be cache invariant.
Fix the one remaining option that is not correctly labelled and add an
unittest to make sure all the options with output path naming convertion
are correctly marked as CacheInvariant.
rdar://146155049
