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
While one can disable building the embedded stdlib, the tests for that
feature were unconditionally added. If one wants to just build the
compiler without any stdlib (except target), a bunch of embedded tests
would have failed.
Inject the value of `SWIFT_SHOULD_BUILD_EMBEDDED_STDLIB` into the Lit
test system as a feature `embedded_stdlib` and add `REQUIRES:` to
a couple of tests outside the `embedded/` directory that seems to use
the experimental feature. Make the tests in `embedded/` unsupported in
the local Lit configuration file.
This warnings don't give much benefits for developers. Code completion
UI tends to show them unusable. But usually, developers can modify the
context to accept async calls, e.g. by wrapping it with `Task { }`
rdar://126737530
Previously code completion for 'catch' pattern bound values didn't work
correctly because code completion type checker fails to type check the
value decl in the pattern.
That was because the body of the 'do' statement is not type checked, so
the thrown error is not determined, then falled backed to the default
'Never', which doesn't matches any patterns.
To resolve this, always type check the body when typechecking 'catch'
patterns. Also, pretends 'do {}' throws 'any Error' even without
any throwing expressions in the body.
rdar://126699879
