Currently, when we jump-to-definition for decls that are macro-expanded
from Clang imported decls (e.g., safe overloads generated by
@_SwiftifyImport), setLocationInfo() emits a bongus location pointing to
a generated buffer, leading the IDE to try to jump to a file that does
not exist.
The root cause here is that setLocationInfo() calls getOriginalRange()
(earlier, getOriginalLocation()), which was not written to account for
such cases where a macro is generated from another generated buffer
whose kind is 'AttributeFromClang'.
This patch fixes setLocationInfo() with some refactoring:
- getOriginalRange() is inlined into setLocationInfo(), so that the
generated buffer-handling logic is localized to that function. This
includes how it handles buffers generated for ReplacedFunctionBody.
- getOriginalLocation() is used in a couple of other places that only
care about macros expanded from the same buffer (so other generated
buffers not not relevant). This "macro-chasing" logic is simplified
and moved from ModuleDecl::getOriginalRange() to a free-standing
function, getMacroUnexpandedRange() (there is no reason for it to be
a method of ModuleDecl).
- GeneratedSourceInfo now carries an extra ClangNode field, which is
populated by getClangSwiftAttrSourceFile() when constructing
a generated buffer for an 'AttributeFromClang'. This could probably
be union'ed with one or more of the other fields in the future.
rdar://151020332
(cherry picked from commit 44aba1382d)
Make `getOriginalLocation` work with source ranges, and adjust the
cursor info logic to map the range into the original buffer. This
fixes the case where we were using bogus range lengths for macro
expansion decls.
rdar://151411756
Ensure we always expand extension macros after the top-level decl
for the given attached decl. This ensures correct unqualified lookup
behavior, and bans macro implementations from extending the
unqualified name (they're expected to use `providingExtensionsOf`
instead, which uses the qualified name).
rdar://148119538
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
When the target decl is a VarDecl, peer macro should expand at the end
of the pattern binding decl, instead of the end of the VarDecl which
only covers the name.
rdar://117098598
Use the attached atttribute's location as the location of the macro,
rather than the location of the declaration it's attached to. Also add
the kind and name of that declaration to the note itself.
Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).
Request would look like:
```
{
key.compilerargs: [...]
key.sourcefile: <file name>
key.sourcetext: <source text> (optional)
key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
key.offset: <offset>
key.modulename: <plugin module name>
key.typename: <macro typename>
key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.
Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. But without `key.buffer_name`. Nested expnasions are not
supported at this point.
`TypeChecker::checkExistentialTypes` has decl-specific logic and backs out without invoking `ExistentialTypeVisitor` on `TypeDecl`s, but `MacroExpansionDecl` isn't a type decl and would fall into `ExistentialTypeVisitor` which will visit its expansion. The caller of `checkExistentialTypes` already visits auxiliary decls, so here we should only visit arguments and generic arguments of a macro.
Fixes a case where a declaration macro produces a type that conforms to a PAT. We now also run existential diagnostics on generic arguments on a `MacroExpansionDecl` that was previously not handled.
Note: I tried bailing out in `walkToDeclPre` but we should really visit macro arguments and generic arguments. Not walking expansions in `ExistentialTypeVisitor` is also not the right fix because we need to be able to visit macro expansions in arguments.
rdar://109779928
Macro expansions are currently written to disk using the mangled name of
the macro. Do not use operators that only differ in case-sensitivity to
avoid issues on case-insensitive filesystems.
Resolves rdar://109371653.
Introduce a new key `generated_buffers`, which
stores an array of generated buffers. These
include the buffer text, as well as its original
location and any parent buffers.
While here, also fix rdar://107281079 such that
only apply the filename fallback logic to the
pretty-printed Decl case. We ought to remove this
fallback once the editor can handle it though.
rdar://107281079
rdar://107952288
Rather than requiring macro implementations to add required whitespace
and indentation, basic format all macro expansions. Right now this uses
the default four space indentation, we can consider having that inferred
later. Macros can opt-out of automatic formatting by implementing
`formatMode` and setting it to `.disabled`.
Also moves the extra newlines before/after expansions to a new "Inline
Macro" refactoring.
Resolves rdar://107731047.
The request returns the expanded buffer ID even if it failed to
typecheck the expanded buffer.
This makes refactoring 'Expand Macro' work regardless of the
typechecking results.
rdar://108530760
Driver uses its path to derive the plugin paths (i.e.
'lib/swift/host/plugins' et al.) Previously it was a constant string
'swiftc' that caused SourceKit failed to find dylib plugins in the
toolchain. Since 'SwiftLangSupport' knows the swift-frontend path,
use it, but replacing the filename with 'swiftc', to derive the plugin
paths.
rdar://107849796
The mangling of attached macro expansions based on the declaration to
which they are attached requires semantic information (specifically,
the interface type of that declaration) that caused cyclic
dependencies during type checking. Replace the mangling with a
less-complete mangling that only requires syntactic information from
the declaration, i.e., the name of the declaration to which the macro
was attached.
This eliminates reference cycles that occur with attached macros that
produce arbitrary names.
The macro tests were all using "REQUIRES: OS=macosx" as a proxy for
"have the Swift Swift parser". There was an existing feature for this,
but it was just checking whether the path was passed through. Fix that
to use the same variable as in CMake.
Also remove all extraneous `-I` and `-L` to the host libs in the target
invocations.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
Pass back the original location (ie. where the macro was expanded, not
the location that the generated code would be inserted) for cursor info
and indexing. Also mark any declarations/references within generated
source as implicit.
Resolves rdar://107209132.
Update requests to handle being passed a separate `key.primary_file`
which specifies the file to use for building the AST. `key.sourcefile`
is then the file to find in `SourceManager`, which could be a generated
buffer.
Resolves rdar://106863186.
