Skip to content

Macro operators without global operator lookup 5.9 #66325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 7 commits into from
Jun 5, 2023
Merged

Macro operators without global operator lookup 5.9 #66325

merged 7 commits into from
Jun 5, 2023

Conversation

DougGregor
Copy link
Member

  • Explanation: Module-scope name lookup tables are used for global operator lookup, which involves that code walking into the members of types to find member operators. This code also unintentionally expanded macros (both peer and freestanding) at member scope, violating the outside-in rule for macro expansion and caused various assertions and circular reference errors. Prevent module-scope lookup from expanding any macros that produce members, so we don't violate this rule. However, this means that member operators introduced via macros won't be found---so make sure they can be found by witness matching, at least.
  • Scope: Narrow; only affects module-scope and global operator lookup involving types with macros that can produce members.
  • Risk: Low; narrow change to the code that builds macros and performs witness matching for types/extensions that have macros.
  • Reviewed by: @hborla
  • Issue: rdar://109219036
  • Original pull request: Only inject macro-introduced operators into module scope #66317, Eliminate macro-generated operators from global operator lookup #66320

DougGregor added 7 commits June 4, 2023 21:24
@DougGregor
[Test] Add test for crash while emitting reference dependencies.
1b537d8 
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.

(cherry picked from commit e6c5871)
@DougGregor
[Test] Ensure that freestanding macros in unprocessed #ifs aren't exp…
fd2fe5a 
…anded.

Tracked by rdar://110083415.

(cherry picked from commit 91e9a2a)
@DougGregor
[Test] Add test for already-fixed macro example.
be67025 
This used to cause a circular reference and crash. No more, but make
sure we don't regress it. From rdar://109280926.

(cherry picked from commit 19ca63a)
@DougGregor
[Module-scope lookup] Only inject macro-introduced operators at modul…
e7321ac 
…e scope

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.

(cherry picked from commit ebe0b63)
@DougGregor
[Macros] Introduce an example where member operators aren't found
84fba88 
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.

(cherry picked from commit 88dd6fc)
@DougGregor
[Module-scope lookup] Don't expand macros associated with members of …
a82ca01 
…types

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.

(cherry picked from commit 343947a)
@DougGregor
Ensure that macro-provided operators can be found by witness lookup
65f8d5b 
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.

(cherry picked from commit b7b6a1d)
@DougGregor DougGregor requested a review from a team as a code owner June 5, 2023 04:33
@DougGregor
Copy link
Member Author

@swift-ci please test

@DougGregor DougGregor merged commit 7203d52 into swiftlang:release/5.9 Jun 5, 2023
@DougGregor DougGregor deleted the macro-operators-without-global-operator-lookup-5.9 branch June 5, 2023 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hborla hborla hborla approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@DougGregor @hborla