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.
Eliminate the error message
error: global freestanding macros not yet supported in script mode
by implementing name lookup, type checking, and code emission for
freestanding macros. The key problem here is that, in script mode,
it is ambiguous whether a use of a freestanding macro is an expression
or a declaration. We parse as an expression (as we do within a
function body), which then gets wrapped in a top-level code
declaration.
Teach various parts of the compiler to look through a top-level code
declaration wrapping a macro expansion expression that is for a
declaration or code-item macro, e.g., by recording these for global
name lookup and treating their expansions as "auxiliary" declarations.
Fixes rdar://109699501.
Address a few related issues that affect local types and opaque result types within macros:
* Don't add local types or opaque types encountered while parsing the
arguments of a freestanding macro to the global list. When we do add
them, make sure we're adding them to the outermost source file so
they'll get seen later. This avoids trying to generate code for these
types, because they aren't supposed to be part of the program. Note
that a similar problem remains for arguments to attached macros, which
will need to be addressed with a more significant refactoring.
* When determining whether opaque types should be substituted within a
resilience domain, check the outermost source files rather than the exact
source file, otherwise we will end up with a mismatch in
argument-passing conventions.
* When delaying the type checking of functions that occur as part of a
macro expansion, make sure we record them in the outermost Swift source
file. Otherwise, we won't come back to them.
There is a common theme here of using AST state on the source file in
a manner that isn't ideal, and starts to break down with macros. In
these cases, we're relying on side effects from earlier phases
(parsing and type checking) to inform later phases, rather than
properly expressing the dependencies through requests.
Fixes rdar://110674997&110713264.
LLVM seems to determine a variable instance as a combination of DILocalVariable
and DILocation. Therefore if multiple llvm.dbg.declare have the same
variable/location parameters, they are considered to be referencing the same
instance of variable.
Swift IRGen emits a set of llvm.dbg.declare calls for every variable
instance (with unique SILDebugScope), so it is important that these calls have
distinct variable/location parameters. Otherwise their DIExpression may be
incorrect when treated as referencing the same variable. For example, if they
have a DIExpression with fragments, we will see this as multiple declarations of
the same fragment. LLVM detects this and crashes with assertion failure:
DwarfExpression.cpp:679: void llvm::DwarfExpression::addFragmentOffset(const
llvm::DIExpression *): Assertion `FragmentOffset >= OffsetInBits &&
"overlapping or duplicate fragments"' failed.
The patch resolves#55703. The LIT test (debug_scope_distinct.swift) is the
reproducer from that issue.
The compiler knows (from a macro declaration) what freestanding macro
role a macro implementation is expected to implement. Pass that through
to the macro expansion code itself, rather than guessing based on the
protocol conformances of the implementation type. We already use this
approach with attached macros, so this is more of the same.
Eliminates a crash and improves diagnostics when the freestanding macro
role and its implementation are out of sync, fixing rdar://110418969.
The parser is currently responsible for adding local type declarations
to a `SourceFile`, which IR generation later queries. However, IRGen
never sees the source files associated with macro expansion buffers,
so local types introduced there don't get recorded.
In time, this approach of using the parser to record semantic
information should be replaced with something more "pull" oriented.
For now, however, record local type declarations in the outermost
enclosing source file... so we see the ones produced by macro
expansions, too.
Fixes rdar://109370309.
When looking for an operator to satisfy a protocol requirement, we
currently depend on global operator lookup for everything except local
types. However, macro-provided operators aren't found by global
operator lookup, so perform a member lookup for such cases in addition
to global operator lookup. This makes macro-provided operators visible
through protocol requirements they witness.
The module-scope lookup tables use the same code for adding
module-scope declarations as for adding member operators, which are
found via "global" operator lookup. This requires us to expand macros
that can produce members of types, which violates the outside-in
expansion rule described in the proposals.
Stop recording member-producing macros, whether they are peer macros
applied to member declarations or are freestanding declaration macros
within a member context. This re-establishes the outside-in expansion
rule. It also means that member operators introduced by macro
expansion won't be found by global operator lookup, which is a
(necessary) semantic change.
Operators introduced by member macros are not getting found by global
operator lookup. This is technically a bug, but due to the potential
cost of having to expand macros on/in types just to find operators,
for now we're just going to document here that it doesn't work and
reconsider the semantics.
Well, this is fun. Due to the use of the module-scope lookup table to
find operators, we need to carefully filter out any macro-introduced
declarations that *aren't* operators when forming the module-scope
lookup table. Otherwise, we can find macro-introduced static entities
within types... from completely unrelated scopes.
Fixes rdar://109219036.
This bug was fixed as part of the rework of our handling of
closure/local discriminators with respect to macros, but add a test
case to ensure that we don't regress. Tracked by rdar://108300632.
Setting closure and local discriminators depends on an in-order walk
of the AST. For macros, it was walking into both macro expansions and
arguments. However, this doesn't work well with lazy macro expansions,
and could result in some closures/local variables not getting
discriminators set at all.
Make the assignment of discriminators only walk macro arguments, and
then lazily assign discriminators for anything within a macro
expansion or in ill-formed code. This replaces the single global "next
autoclosure discriminator" scheme with a per-DeclContext scheme, that
is more reliable/robust, although it does mean that discriminators
of closures and locals within macro expansions are dependent on
ordering. That shouldn't matter, because these are local values.
Fixes rdar://108682196.
An incorrectly-specified starting context for name lookup meant that
macro lookup itself was failing, and therefore did not trigger
expansion of the freestanding macro or introduction of the
macro-expanded declarations into the context.
Fixes rdar://108824784.
This could cause us to double up on the same note
for nested macro expansions, as we'd generate the
note, then when recursing back through the function
we'd compute the same note again. Also remove the
seemingly unused `lastBufferID` param.
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.
Before this patch the parents of SILDebugScopes representing macro expansions
were missing the inlinedAt field, which resulted in incorrent LLVM IR being
produced. This is fixed by first computing the inlined call site for a macro
expansion and then computing the nested SILDebugScope for the ASTScope of the
expanded nodes; adding the inlinedAt field to all of levels of parent scopes.
rdar://108323748
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.
Eliminate a source of cyclic dependencies by not expanding macros when
we are resolving macro arguments within a type or extension context.
This extends the scheme introduced for module-scope lookup to also
apply to lookup within types.
This patch replaces the stateful generation of SILScope information in
SILGenFunction with data derived from the ASTScope hierarchy, which should be
100% in sync with the scopes needed for local variables. The goal is to
eliminate the surprising effects that the stack of cleanup operations can have
on the current state of SILBuilder leading to a fully deterministic (in the
sense of: predictible by a human) association of SILDebugScopes with
SILInstructions. The patch also eliminates the need to many workarounds. There
are still some accomodations for several Sema transformation passes such as
ResultBuilders, which don't correctly update the source locations when moving
around nodes. If these were implemented as macros, this problem would disappear.
This necessary rewrite of the macro scope handling included in this patch also
adds proper support nested macro expansions.
This fixes
rdar://88274783
and either fixes or at least partially addresses the following:
rdar://89252827
rdar://105186946
rdar://105757810
rdar://105997826
rdar://105102288
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.
When populating the name lookup tables with macro-expanded declarations,
we were careful to avoid full macro resolution for attached macros, but
freestanding macros were will doing full resolution. Switch
freestanding macros over to the same partial resolution mechanism to
avoid reference cycles.
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
Teach ASTScope to create child nodes for each of the arguments of a
macro expansion declaration, so that we can perform name lookup into
them. Otherwise, we cannot have nontrivial closures in arguments to a
macro expansion declaration.
Fixes rdar://107388151.
In preparation for supporting macros that are defined in terms of other
macros, adopt macro definition checking provided by the
`MacroDeclSyntax.checkDefinition` operation (implemented in
swift-syntax). Use this in lieu of the checking on the C++ side.
This required me to finally fix an issue with the source ranges for
Fix-Its, where we were replacing the leading/trailing trivia of nodes
along with the node itself, even though that's incorrect: we should
only replce the node itself, and there are other Fix-It kinds for
replacing leading or trailing trivia.
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
When loading plugins from `-plugin-path`, use the global `PluginRegistry` to keep a record of what's loaded. Emit these dependencies to the loaded module trace.
