This routine was never properly updated to handle layout requirements, conditional conformances,
or parameter packs. Let's clear out the FIXMEs and do things properly here.
Fixes https://github.com/swiftlang/swift/issues/76561
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of opaque types, instead
of disabling availability checking.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
My change to preserve type sugar in type transforms introduced a
performance regression here, because openType() is called for
every disjunction choice.
My hope is to optimize the TypeAliasType representation and remove
this at some point, but for now, let's just restore the old
desugaring behavior in this case.
A couple of tests are expecting merge-modules behaviour,
add `-no-emit-module-separately` in those cases to
ensure that merge modules is used in both the old
and new driver.
We're using a small custom frontend tool to generate indexstore data for `.swiftinterface` files in the SDKs. We do this by treating the `.swiftinterface` file as the input of an interface compilation, but this exits early because it treats it as a `SourceFile` instead of an external `LoadedFile`. This happens even if we call `setIsSystemModule(true)` unless we skip setting the SDK path, but that causes other problems. It seems harmless to check for `SourceFile`s as well, so that a tool processing an SDK interface as a direct input still gets the right state.
The option to print #ifs defaulted to "on", but was disabled in most of
the actual compiler inputs that mattered, and the results weren't ever
actually used. Remove the option so we never print #ifs.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
There was a bunch of logic to lazily populate replacement types
corresponding to reducible generic parameters. This didn't seem
to have a clear purpose so let's remove it.
Add a case for completing type attributes in
inheritance clause position, and limit the
completion of `@unchecked`, `@preconcurrency`, and
`@retroactive` to that case.
Attempting to favor a disjunction choice here
can lead to unhelpful results if there's e.g a code
completion token argument, since it acts as a
placeholder.
rdar://127844278
Complete ownership specifiers such as `consuming`,
`borrowing`, and `inout` in parameter type
position. While here, also complete `isolated`.
rdar://127261573
Defining it as a `DECL_KEYWORD` means code
completion will try and complete it in decl
position. It shouldn't really be considered a decl
keyword, so define it as `SWIFT_KEYWORD`.
If the extension does not match the protocol type
that we're doing the lookup for, check whether the
`Self` type conforms to the protocol; in that case
we have e.g an extension for an inherited protocol.
rdar://129024996
Previously we would skip any expression in a
result builder that didn't contain the completion
token, but that would cause issues if e.g the
result builder was needed to infer the type of a
variable that we're completing on. Instead, only
skip expressions in a result builder if the
completion token is in the same builder and the
expression itself doesn't contain the completion.
rdar://127154780
For unresolved member completion, we were preferring
the more general type, when we ought to be preferring
the more specific type. Additionally, for both
unresolved member and postfix completion we were
opening archetypes, which doesn't work as expected
since we don't compare requirements. Factor out
the logic that deals with merging base types for
lookup, and have it prefer either the subtype, or
the optional type in the case of optional promotion.
rdar://126168123
`Res.FirstTrailingClosureIndex` is an index into
the argument list, so comparing it against a
parameter index is wrong. Instead, compare it
against the argument index of the completion token,
which is what we want to be checking. This ensures
we don't try and offer argument completions for
non-function default arguments.
rdar://127760308
