**Overview**:
This PR introduces the basic infrastructure needed to eventually migrate
derived macros generation from hand-crafted AST nodes to macros. No
conformance have been migrated yet.
**Motivation**:
Derived conformances (e.g. `Equatable`, `Hashable`, `Codable`, ...) are
currently implemented as a special case in the compiler, producing
synthetic AST nodes directly. Migrating this to macros will hopefully
unify the code path with the existing macro expansion infrastructure,
make conformance synthesis easier to extend and test as well as reducing
the amount of special cases in the compiler.
**Changes**:
- New experimental feature flag `DeriveConformancesViaMacros`:
Introduces the flag that will eventually gate the new derived
conformance code paths. It does not control any behaviour for the moment
as none have been migrated yet but this enables future changes to be
built incrementally.
- New GeneratedSourceInfo and SourceFile kinds `SyntheticMacro`:
Introduces new GSI and SourceFile kinds named `SyntheticMacro` to
represent macros synthesized by the compiler. Since macros need a real
buffer to expand, this is the kind of source file and GSI associated
with those buffers.
- Conformance derivation via macros API:
Introduces the `deriveRequirementViaMacro` function that produces the
required witness via macro expansion.
See https://github.com/swiftlang/llvm-project/pull/13124 for
llvm-related changes.
**Next steps**:
- Macros do not contain any semantic information, especially regarding
types. Therefore it is necessary to provide them with type information
as an argument so they can eventually derive the conformances. A
separate PR is being created to generate this type information as
strings containing swift-parsable code for easy parsing on the macro
end.
- Implement derived conformance synthesis for individual protocols using
the new infrastructure, like `Equatable` or `Hashable` for starters.
- Wire the experimental flag to gate the new path once an implementation
exists
---------
Co-authored-by: Hamish Knight <hamish_knight@apple.com>
Otherwise these source file objects linger in the source manager but they refer to a fully-temporary 'ASTContext' which does not exist after parsing is complete, which means they cannot be used in any way and attempting to do so would lead to a crash.
This case is currently being hit for code completion, possibly due
to an invalid ASTScope node range. Let's bail in non-asserts builds
rather than crashing when attempting to access the generated source
info.
rdar://134522702
Given we're working with CharSourceRanges, the end location is past
the end of the actual range, so when checking if e.g a function body
macro is contained within the function decl, we fail since the end
location is past the closing `}`. Check the start location instead,
which is part of the range.
We use experimental features to let people know that the construct is
subject to change and users should not rely on this unless they are
willing to rewrite the uses of this feature later. However, in compiler
generated code everything should be fair game, we will update the
compiler when these features change. This is a requirement to be able to
turn safe wrapper generation on by default.
Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
Now that every source file has a buffer ID, introduce the reverse mapping
so clients can find the source file(s) in their module that reference
that buffer ID.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Test shadowed variable of same type
Fully type check caller side macro expansion
Skip macro default arg caller side expr at decl primary
Test macro expand more complex expressions
Set synthesized expression as implicit
Add test case for with argument, not compiling currently
Test with swiftinterface
Always use the string representation of the default argument
Now works across module boundary
Check works for multiple files
Make default argument expression work in single file
Use expected-error
Disallow expression macro as default argument
Using as a sub expression in default argument still allowed as expression macros behave the same as built-in magic literals
Avoid forming invalid source ranges when
`ReturnLoc` is invalid. Also introduce a utility
to make this kind of range computation easier,
and use it in a couple of other cases.
original source location of a macro expansion when walking up the ancestor
list.
The original source range of a macro expansion buffer contains the entire
range of the code that is replaced by the expansion. In some cases, the
original code is type checked, so ASTScope needs to represent both the
original code and the macro-expanded code in the scope tree.
For accessor macros, the original code -- the initializer expression of
the property -- is type checked, but not before macro expansion, so
unqualified lookup must deal with the scope tree for the initializer and
the expanded accessors. The accessors are inserted in the tree after the
initializer scope, but the `isBeforeInSource` was using the start location
of the original source range for macro expansions, so the accessor scopes
were incorrectly considered to be ordered before a source location in the
initializer expression, which caused unqualified lookup of local variables
within the initializer to fail.
ASTScope assertions that a new child node inserted into its parent list
is after all other child nodes in the source, which included some bespoke
code for dealing with macro expansions. Replace this bespoke code with
uses of the newer SourceManager operations that check ordering of
source locations in a manner that respects macro expansions.
SourceManager's `isBeforeInBuffer` in buffer takes two source locations
that are assumed to be within the same source buffer and determines
whether the first precedes the second. However, due to macro
expansion, there can be source locations in different source buffers
that are nonetheless conceptually part of the same source file. For
such cases, `isBeforeInBuffer` will silently produce wrong results.
Extend `SourceManager` with a new `isBefore` operation that determines
whether one source location precedes another in the same conceptual
source file, even if they are in different source buffers that (e.g.)
represent macro expansions within that source file. Also introduce
`isAtOrBefore` to cover the case where the source locations might be
equivalent, which was previously handled via a separate equality check
on the source locations that won't work with macro expansions.
Add caching for the list of accessors of a buffer, so we aren't doing
a full walk up the source-buffer chain ever time we do a comparison of
source locations. LCA is still linear-time, but this eliminates
extraneous hash table lookups along the way.
Over time, we should both move more clients over to these new variants
and introduce more assertions into the old (in-buffer) versions to
catch improper uses of them.
This function was performing a linear scan through the set of known
buffers to find the buffer containing a given source location. This
linear scan can show up in hot loops, and the number of buffers in a
program is increasing due to macros, so this has become a performance
problem.
Replace the linear scan with a logarithmic lookup into a sorted vector
of the buffer IDs, with a one-element most-recently-used cache so that
repeated lookups in the same buffer require constant time.
This mirrors what we already do with source files in a module.
Unfortunately, we cannot reuse that code because there is no link from
buffers to source files. We should look to consolidate this in the
future.
Fixes rdar://116184248.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
We may want to revisit this in the future, but for
now let's avoid profiling code in generated
buffers. To make this work we'll need to come up
with a scheme for writing out the generated buffers
such that tools like `llvm-cov` can reference them.
rdar://109562235
Macro expansion buffers, along with other generated source buffers,
need more precise "original source ranges" that can be had with the
token-based `SourceRange`. Switch over to `CharSourceRange` and provide
more thoughtfully-determined original source ranges.
The main problem that prevented us from reusing the ASTContext was that we weren’t remapping the `LocToResolve` in the temporary buffer that only contains the re-parsed function back to the original buffer. Thus `NodeFinder` couldn’t find the node that we want to get cursor info for.
Getting AST reuse to work for top-level items is harder because it currently heavily relies on the `HasCodeCompletion` state being set on the parser result. I’ll try that in a follow-up PR.
rdar://103251263
When emitting a diagnostic that references a declaration that does not
itself have a source location (e.g., because it was synthesized or
deserialized), the diagnostics engine pretty-prints the declaration
into a buffer so it can provide caret diagnostics pointing to that
declaration.
Start marking those buffers as "generated source buffers", so that we
emit their contents into serialized diagnostics files. This will allow
tools that make use of serialized diagnostics to also show caret
information.
Establish the relationship for generated sources, whether for macro
expansions or (via a small stretch) replacing function bodies with
other bodies, in the source manager itself. This makes the information
available for diagnostic rendering, and unifies a little bit of the
representation, although it isn't used for much yet.
`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
Paul Passeron
Artem Chikin
Anthony Latsis
Hamish Knight
Gabor Horvath
Doug Gregor
Saleem Abdulrasool
Jeremy Day
Rintaro Ishizaki
Tim Kientzle
Konrad `ktoso` Malawski
Ben Barham
Apollo Zhu
Holly Borla
Evan Wilde
Hamish Knight
Alex Hoppen
Andrew Trick
Erik Eckstein
Anthony Latsis
Fredrik Wieczerkowski