These were replaced by `#file`, `#line`, etc. with SE-0028, prior to
Swift 3. We don't need this custom error message any more, and they
shouldn't be keywords. Stop treating them as keywords in the lexer.
`passReference` was failing to find the underlying declaration for a
constructor reference. In this case it was for a
`FunctionConversionExpr`, but there's likely others. Use
`ide::getReferencedDecl` instead.
Resolves rdar://102563191.
This brings up the ability to compute cursor info results using the completion-like type checking paradigm, which an reuse ASTContexts and doesn’t need to type check the entire file.
For now, the new implementation only supports cursor info on `ValueDecl`s (not on references) because they were easiest to implement. More cursor info kinds are coming soon.
At the moment, we only run the new implementation in a verification mode: It is only invoked in assert toolchains and when run, we check that the results are equivalent to the old implementation. Once more cursor info kinds are implemented and if the SourceKit stress tester doesn’t find any verification issues, we can enable the new implementation, falling back to the old implementation if the new one didn’t produce any results.
We need the ability to type check declarations when entering using `typeCheckASTNodeAtLoc` for solver-based cursor info.
This causes more context to be type checked for code completion and breaks some type completion after dot if the base type is not fully qualified because the type checker will mark `TypeRepr` as invalid. But since we don’t actually need to run the type checker for type member completion, we can just not call `typeCheckContextAt` for `TypeIdentifierWithDot` completions.
This will be necessary to make cursor info completion like to inspect the just parsed source file because the callback from parsing the code completion token won’t be called.
This way, each kind of `ResolvedCursorInfo` can define its own set of properties and it’s obvious which properties are used for which kind. Also switch to getters and setters because that makes it easier to search for usages of properties by looking at the call hierarchy of the getter / setter.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
IDE/Refactoring had dependencies to libswiftIndex, but libswiftIndex
also depends on libswiftIDE (SourceEntityWalker, etc.)
To break libswiftIndex <-> libswiftIDE dependency cycle, move
"refactoring" related files to a new library 'libswiftRefactoring'
rdar://101692282
These libraries formed a strongly connected component in the CMake build graph. The weakest link I could find was from IDE to FrontendTool and Frontend, which was necessitated by the `CompileInstance` class (https://github.com/apple/swift/pull/40645). I moved a few files out of IDE into a new IDETools library to break the cycle.
`lookupVisibleMemberDecls` visits nominal type decls to find visible
members of the type. Remembering what decls are visited can be useful
information for the clients.
* Add a 'VisibleDeclConsumer' callback function that is called when
'lookupVisibleDecls' visits each nominal type decls
* Remember the decl names in 'CodeCompletionContext' for future use
Introduce `MacroExpansionExpr` and `MacroExpansionDecl` and plumb it through. Parse them in roughly the same way we parse `ObjectLiteralExpr`.
The syntax is gated under `-enable-experimental-feature Macros`.
