Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
Various requests expect to be walking over the current source file.
While we could add checks to all these to skip decls outside of the
current buffer, it's a little nicer to handle this during the walk
instead.
Allow ignoring nodes that are from macro expansions and add that flag to
the various walks that expect it.
Also add a new `getOriginalAttrs` that filters out attributes in
generated source.
The macro role argument presented an opportunity for callers to accidentally
invoke this request twice for the same macro with slightly different macro
roles passed in, which resulted in re-typechecking the macro arguments.
Instead, derive the corresponding macro roles from the macro reference syntax.
Extend the macro-expansion refactoring to work with member and
member-attribute attached macros. These expansions can return several
different changes, e.g., adding new members, sprinkling member
attributes around, and so on.
`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.
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
Turns out we were getting away with dereferencing
`nullptr` in a few cases as `walk` would use
`nullptr` to indicate that the walk should be
stopped, and luckily Clang didn't optimize it to
something broken.
This commit is fairly defensive and sprinkles
some null checks for calls to `walk` directly
on a body of a function or top-level code decl.
When a value is initialized or coerced for a type that conforms to
one of the `ExpressibleBy*Literal` protocols (or
`ExpressibleByStringInterpolation`), this change records an implicit
call to the corresponding `init(...Literal:)` in the indexstore,
located at the beginning of the literal.
* InterfaceGen reports a primary associated type as a reference to the
'associatedtype' declaration
* CursorInfo on a primary associated type returns information of the
'associatedtype' declaration
rdar://93275458
`SemaAnnotator` always attempts to retrieve the location of the decl. This
requires generating the USR, which needs to resolve the type. But that's
invalid in the presence of `@_implementationOnly`.
This most commonly comes up during index while building as even though
it skip internal decls, by that point it's too late (`SemaAnnotator` has
already tried retrieving the location). Other uses of
`SourceEntityWalker` should be unaffected as they only run over the
current decls in the current module.
For now skip walking internal top level decls from serialized modules in
`SemaAnnotator`. Consider expanding this to most, if not all,
`ASTWalker` clients in the future - it's unlikely `SemaAnnotator` is the
only one with this problem.
Resolves rdar://91279771.
References associated with a `VarDecl` had no `RelationContainedBy` role, resulting in "orphaned" references. From the perspective of identifying unused code (in tools using the index, like [Periphery](https://github.com/peripheryapp/periphery)), this made it impossible to identify that a variable's type, initializer and custom attributes are associated with the variable.
Resolves: [SR-13766](https://bugs.swift.org/browse/SR-13766)
SemaAnnotator was walking into an autoclosure and then manually running
`passReference` on the unwrapped expression without walking it. Since
its synthesized anyway, skip walking the autoclosure entirely and walk
the unwrapped expression instead.
Fix `swift::ide::isBeingCalled` to look through `IdentityExpr`s and
`swift::ide::getBase` also not unwrapping curry thunks.
Resolves rdar://81312849
This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
Abstract away the TupleExpr gunk and expose
`getLHS` and `getRHS` accessors. This is in
preparation for completely expunging the use
of TupleExpr as an argument list.
We had some unbalanced calls of `walkTo*Pre` and `walkTo*Post` in `SemaAnnotator`.
The main fix was to set `Cancelled` to `true` if traversal is being stopped in `walkToExprPre`.
While I was at it, I also
- Added some more checks, ensuring that no more `walkTo*` calls are issued after `Cancelled` has been set to `true`.
- Added some comments, describing the intended traversal behaviour.
- Inverted the return value of the `ReportParamList` lambda to be in line with the return value of the enclosing `walkToDeclPre`
- Moved `walkToExprPost` to be place right after `walkToExprPre`
Resolves rdar://64139829 [SR-12957]
`visitTopLevelCodeDecl` ignored the `Stmt` visit returning a nullptr.
This caused the `walkToDeclPost` to run for the `TopLevelCodeDecl` and
thus an imbalance in the `RangeResolver` pre and posts (since none of
the children would have their `walkTo*Post` called).
This was originally incorrectly fixed while assuming that the
`walkTo*Post` are called regardless of whether the children were visited
or not. Those changes have been reverted - fixing an imbalance in
`ExtDecls` in `SemaAnnotator`.
Added a test case for the `ExtDecls` imbalance which can occur while an
extension is being added.
Resolves rdar://74820040
`SourceEntityWalker` had an unbalanced `walkToDeclPre` and
`walkToDeclPost`, ie. `walkToDeclPost` could be called even though
`walkToDeclPre` was not. Specifically, this would occur for both
`OperatorDecl` and `PrecedenceGroupDecl` declarations.
These could both be added to the `if` in `walkToDeclPost`, but this
seems fairly errorprone in general - especially as new decls are added.
Indeed, there's already declarations that are being skipped because they
aren't explicitly tested for in `walkToDeclPre`, ie.
`PatternBindingDecl`.
Instead of skipping if not explcitly handled, only skip running the
`SEWalker` walk methods if the declaration is implicit (and not a
constructor decl, see TODO). This should probably also always visit
children, with various decls changed to become implicit (eg.
TopLevelCodeDecl), but we can do that later - breaks too many tests for
now.
This change exposed a few parameter declarations that were missing their
implicit flag, as well as unbalanced walk methods in `RangeResolver`.
Hit this crash while walking an `import protocol ...` declaration.
Check loc validity before calling `SourceManager::extractText`:
there is an assertion at the beginning of this function.
rdar://65258208
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
This change makes us treat it exactly as we do 'init'. We don't allow renaming the base name,
and don't fail if the basename doesn't match for calls.
Also:
- explicit init calls/references like `MyType.init(42)` are now reported with
'init' as a keywordBase range, rather than nothing.
- cursor info no longer reports rename as available on init/callAsFunction
calls without arguments, as there's nothing to rename in that case.
- Improved detection of when a referenced function is a call (rather than
reference) across syntactic rename, cursor-info, and indexing.
Resolves rdar://problem/60340429
