The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
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
For example when we have
```swift
protocol BaseProtocol {}
extension BaseProtocol {
/// Say hello
func hello() { }
}
struct MyStruct: BaseProtocol {
func hello() {}
}
```
Then `MyStruct.hello` should inherit the doc comment from the implementation of `BaseProtocol.hello`. Currently no doc comment is associated with `MyStruct.hello`.
rdar://126240546
We ran SwiftParser in `handlePrimaryAST` for related identifiers. That function is called on a dispatch queue with reduced stack size and could cause the parser to stack overflow if the program is very nested.
Run `handlePrimaryAST` on a deep stack for this request to fix the issue.
rdar://129960285
As much as possible, we should avoid using `REQUIRES: maccatalyst_support`
since tests restricted this way are not run in PR tests. Many tests that
exercise macCatalyst behaviors can be run in a macOS configuration, without
full macCatalyst standard library support.
Also, adopt `%target-cpu` lit substitution where appropriate to avoid needless
standard library module rebuilds when running tests locally.
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.
These won't have bodies in generated interfaces,
and generally aren't useful things to jump to. The
property ought to be used instead.
rdar://130775560
Previously we would skip resolving any solver-based
cursor info in a VarDecl accessor as the VarDecl
source range does not encompass the AccessorDecl.
Avoid looking at the VarDecl source range in this
case.
rdar://131135631
Replace the assert-check if a vtable is available with a regular error message.
This cannot occur in regular builds - only if built with embedded swift and without wmo.
The command line compiler prevents this combination, but it can happen in SourceKit.
rdar://130167087
Previously we would strictly match `{` + `}`, but
that ignored the fact that when parsing we consider
`#if` + `#endif` to be a stronger delimiter than
`{` + `}`, so can ignore a stray `}` in a `#if`.
Update the logic to also track opening and closing
`#if` decls, ignoring any braces that happen within
them.
rdar://129195380
Ensure we always produce typed AST, even if we
fail to apply a solution. This fixes a cursor info
issue where we'd to type-check a closure twice
due to it not having a type set.
rdar://129417672
We treated enum case parameters the same way as function parameters and weren’t considering that they can be unlabeled. That caused us to insert eg. `_ ` in front of the case’s type, producing `case myCase(_ String)`, which is invalid. When we are inside an enum case parameter and the parameter label is empty, treat it the same as a function call, which will leave the label untouched if it isn’t modified and insert a label including a colon if a new label is introduced.
https://github.com/apple/sourcekit-lsp/issues/1228
Previously we would mangle a single ErrorType as
the type for the element, but that would fail to
demangle since we expect a function type. Use the
same logic as AbstractFunctionDecl, mangling a
function type of ErrorType. While here, also
handle SubscriptDecls and check for error types
rather than `isInvalid()`.
rdar://129065620
We only set `isDynamic` to `true` if we were inside an expression. Also set `isDynamic` when we are performing cursor info at an overridable declaration. This allows jump-to-definition to jump to declarations that override the one that we performed cursor info on.
rdar://128300752
It appears that a6ebd3083d changed the behavior of `-fno-modules-validate-system-headers` (aka. `DisableModulesValidateSystemDependencies`) in conjunction with `-fmodules-validate-once-per-build-session`: Before that change, `-fno-modules-validate-system-headers` needed to be passed for `-fmodules-validate-once-per-build-session` to have any effect (we were always validating system dependencies if `-fno-modules-validate-once-per-build-session` was not set). After the change, `-fno-modules-validate-once-per-build-session` causes system dependencies to never be validated, independent of the build session timestamp.
This change should have no effect on Xcode because it adds `-fmodules-validate-system-headers` to the compiler arguments for Swift files, which overrides `SearchPathOpts.DisableModulesValidateSystemDependencies = true;`
We do iterate into extern C declarations when building the Swift lookup table during PCH generation.
0fad799f51/lib/ClangImporter/SwiftLookupTable.cpp (L2140-L2146)
However, we don’t import `extern "C"` declarations while parsing the bridging header (eg. when no `-pch-output-dir` is specified during code completion). This caused us to miss functions annotated as `extern "C"` in code completion.
rdar://127512985
For example, the following declarations have the same USR with a single ERROR_TYPE parameter despite being distinct declarations.
```swift
func bar(body: Invalid) {}
func bar(ignoreCase: Bool, body: Invalid) {}
```
We originally intended to check the USR so that local rename behaves more like global rename, which also looks symbols up by USR. But the above example proves that assumption wrong.
rdar://126803702
