This fixes an immediate bug with subst-to-orig conversion of
parameter functions that I'm surprised isn't otherwise tested.
More importantly, it preserves valuable information that should
let us handle a much wider variety of variant representations
that aren't necessarily expressed in the AbstractionPattern.
Previously we were using `getPlainType` to match
the parameter type against the key path's base
type. This gave us the external parameter type,
which would be the element type for a variadic
parameter. However the code we generate expects
the internal parameter type, which is provided by
`getParameterType`.
Resolves rdar://problem/59445486.
Compatibility header may #import bridging header if specified with -import-underlying-module.
How these two headers are relative to each other is subject to project setting. To accommodate
this, we should allow users to specify bridging header directory for header generating purposes.
rdar://59110975
- In member completions, when 'callAsFunction' decls are found, suggest
call patterns
- In call pattern completions, fallback to search 'callAsFunction' if
the base type is not a function type
rdar://problem/59792682
If the substituted type for a conformance found via a superclass constraint is a subclass of that
superclass, then we should represent that with an InheritedProtocolConformance rather than with
the original root conformance that applies to the superclass. If we don't do this, then we end up
with spurious inequalities in generic signatures that ought to be equivalent, because some
paths use the inherited conformance and some don't, as in SR-12330 | rdar://problem/60174186.
Doing this requires us to re-introduce the concept of the contextual generic signature to SIL type lowering, but hopefully just in a few places.
As the FIXME notes, I found a problem here for substituted function types, but I need to land this first to fix ProcedureKit in the source-compatibility test suite.
EscapeAnalysis::mayReleaseContent was recently changed to assert on
address-type arguments. The assert ensures that callers directly pass
the reference being released. If the caller does not have the precise
reference being released, it opens the door to bugs in which the
EscapeAnalysis query looks up the wrong connection graph node.
The original AliasAnalysis logic is just a workaround for the fact
that we don't have information about which builtin's may release
reference-type arguments.
Fixes <rdar://60190962> Escape analysis crashes with "an address is
never a reference" error with -O -thread=sanitize
- Rename several symbols to make it clearer whether the ranges they deal with
are open or closed.
- Add comments documenting the implementation of OutdentChecker::hasOutdent
- Fix a bug where code after a doc coment block of the '/**' style was being
indented 1 space.
- Fix IsInStringLiteral not being set if the indent target was in a string
segment of an interpolated multiline string.
- Update OutdentChecker::hasOutdent to propagate indent contexts from
parent parens/brackets/braces to child parens/brackets/braces that start
later in the same line (like FormatWalker already does). This changes the
braces in the example below to 'inherit' a ContextLoc from their parent
square brackets, which have a ContextLoc at 'foo'. This makes the whole
expression be correctly considered 'outdenting':
foo(a: "hello"
b: "hello")[x: {
print("hello")
}]
This restructures the indentation logic around producing a single IndentContext
for the line being indented. An IndentContext has:
- a ContextLoc, which points to a source location to indent relative to,
- a Kind, indicating whether we should align with that location exactly, or
with the start of the content on its containing line, and
- an IndentLevel with the relative number of levels to indent by.
It also improves the handling of:
- chained and nested parens, braces, square brackets and angle brackets, and
how those interact with the exact alignment of parameters, call arguments,
and tuple, array and dictionary elements.
- Indenting to the correct level after an incomplete expression, statement or
decl.
Resolves:
rdar://problem/59135010
rdar://problem/25519439
rdar://problem/50137394
rdar://problem/48410444
rdar://problem/48643521
rdar://problem/42171947
rdar://problem/40130724
rdar://problem/41405163
rdar://problem/39367027
rdar://problem/36332430
rdar://problem/34464828
rdar://problem/33113738
rdar://problem/32314354
rdar://problem/30106520
rdar://problem/29773848
rdar://problem/27301544
rdar://problem/27776466
rdar://problem/27230819
rdar://problem/25490868
rdar://problem/23482354
rdar://problem/20193017
rdar://problem/47117735
rdar://problem/55950781
rdar://problem/55939440
rdar://problem/53247352
rdar://problem/54326612
rdar://problem/53131527
rdar://problem/48399673
rdar://problem/51361639
rdar://problem/58285950
rdar://problem/58286076
rdar://problem/53828204
rdar://problem/58286182
rdar://problem/58504167
rdar://problem/58286327
rdar://problem/53828026
rdar://problem/57623821
rdar://problem/56965360
rdar://problem/54470937
rdar://problem/55580761
rdar://problem/46928002
rdar://problem/35807378
rdar://problem/39397252
rdar://problem/26692035
rdar://problem/33760223
rdar://problem/48934744
rdar://problem/43315903
rdar://problem/24630624
We need this anyways for -Onone and I want to do some experiments with running
this very early so I can expose more of the stdlib (modulo inlining) to the new
ownership optimizing passes.
I also changed how the inliner handles inlining around OSSA by changing it to
check early that if the caller is in ossa, then we only inline if all of the
callees that the caller calls are in ossa. The intention is to hopefully avoid
weird swings in code-size/perf due to the inliner heuristic's calculation being
artificially manipulated due to some callees not being available to inline (due
to this difference) when others are already available.
* Use in_guaranteed for let captures
With this all let values will be captured with in_guaranteed convention
by the closure. Following are the main changes :
SILGen changes:
- A new CaptureKind::Immutable is introduced, to capture let values as in_guaranteed.
- SILGen of in_guaranteed capture had to be fixed.
in_guaranteed captures as per convention are consumed by the closure. And so SILGen should not generate a destroy_addr for an in_guaranteed capture.
But LetValueInitialization can push Dealloc and Release states of the captured arg in the Cleanup stack, and there is no way to access the CleanupHandle and disable the emission of destroy_addr while emitting the captures in SILGenFunction::emitCaptures.
So we now create, temporary allocation of the in_guaranteed capture iduring SILGenFunction::emitCaptures without emitting destroy_addr for it.
SILOptimizer changes:
- Handle in_guaranteed in CopyForwarding.
- Adjust dealloc_stack of in_guaranteed capture to occur after destroy_addr for on_stack closures in ClosureLifetimeFixup.
IRGen changes :
- Since HeapLayout can be non-fixed now, make sure emitSize is used conditionally
- Don't consider ClassPointerSource kind parameter type for fulfillments while generating code for partial apply forwarder.
The TypeMetadata of ClassPointSource kind sources are not populated in HeapLayout's NecessaryBindings. If we have a generic parameter on the HeapLayout which can be fulfilled by a ClassPointerSource, its TypeMetaData will not be found while constructing the dtor function of the HeapLayout.
So it is important to skip considering sources of ClassPointerSource kind, so that TypeMetadata of a dependent generic parameters gets populated in HeapLayout's NecessaryBindings.
The design implemented in this patch is that we lower the types of accessors with pattern substitutions when lowering them against a different accessor, which happens with class overrides and protocol witnesses, and that we introduce pattern substitutions when substituting into a non-patterned coroutine type. This seems to achieve consistent abstraction without introduce a ton of new complexity.
An earlier version of this patch tried to define witness thunks (conservatively, just for accessors) by simply applying the requirement substitutions directly to the requirement. Conceptually that should work, but I ran into a lot of trouble with things that assumed that pattern substitutions didn't conceal significant substitution work. for example, resolving a dependent member in a component type could find a new use of an opaque archetype when the code assumed that such types had already been substituted away. So while I think that is definiteely a promising direction, I had to back that out in order to make the number of changes manageable for a single PR.
As part of this, I had to fix a number of little bugs here and there, some of which I just introduced. One of these bugfixes is a place where the substitution code was trying to improperly abstract function types when substituting them in for a type parameter, and it's been in the code for a really long time, and I'm really not sure how it's never blown up before.
I'm increasingly of the opinion that invocation substitutions are not actually necessary, but that --- after we've solved the substitution issues above --- we may want the ability to build multiple levels of pattern substitution so that we can guarantee that e.g. witness thunks always have the exact component structure of the requirement before a certain level of substitution, thus allowing the witness substitutions to be easily extracted.
Requirements on extensions were only being gathered indirectly. This adds a new
optional field to `conformsTo` relationship edges, `swiftConstraints`, which
provides the requirements there.
rdar://60091161
