Skip to content
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.

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

Add Span::unique_site #60106

Closed
wants to merge 2 commits into from
Closed

Add Span::unique_site #60106

wants to merge 2 commits into from

Conversation

mjbshaw
Copy link
Contributor

@mjbshaw mjbshaw commented Apr 19, 2019

A little bit of background: Feedback on Span::def_site

Span::def_site is useful in that call-site code cannot access identifiers which use it. But it doesn't prevent identifier clashes within the macro, particularly when the macro is implemented using several subcomponents, each of which generates a portion of the macro. These subcomponents may use conflicting identifiers.

The new Span::unique_site solves this problem. Each call to Span::unique_site generates a new span that resolves at a unique site. It allows a macro to isolate parts of its expansion from each other.

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 19, 2019
@petrochenkov petrochenkov self-assigned this Apr 19, 2019
src/libproc_macro/lib.rs Outdated Show resolved Hide resolved
@Centril
Copy link
Contributor

Centril commented Apr 19, 2019

r? @petrochenkov

@petrochenkov
Copy link
Contributor

petrochenkov commented Apr 21, 2019

I need to think how to do this properly, so it may take some time.

Adding a new Transparency variant for this doesn't seem right, and giving users the power to create Symbol::gensyms could interfere with compiler's implementation details.

@petrochenkov
Copy link
Contributor

I'm going to close this, I think.
This needs an RFC including motivation and some more detailed design / specification.

How to approach writing such an RFC.

  1. Audit all uses of gensym in the compiler and figure out which uses could be satisfied by Span::def_site and which could not.
  2. Describe use cases that cannot be satisfied by Span::def_site in detail.
  3. Attempt to address those use cases with Span::unique_site introduced as a Span::def_site of a "freshly introduced macro" and see whether it fits.
  4. Attempt to address use cases from outside the compiler with Span::unique_site introduced as a Span::def_site of a "freshly introduced macro" and see whether it fits.

The motivation for introducing Span::unique_site through Span::def_site is to have one mechanism for gensyms-and-similar-things rather than two, and to get rid of the existing gensym implementation in the compiler.

@mjbshaw
Copy link
Contributor Author

mjbshaw commented Apr 28, 2019

@petrochenkov Sorry, I'm not sure I fully understand your comment. I'm not sure if Span::unique_site is useful within the compiler, and I have no idea how gensym is used within the compiler. My motivation is to use Span::unique_site in user code (procedural macros, specifically), much like I'd want to use gensym in Lisp (or Racket, which is the Lisp dialect I have experience with). There is no gensym mechanism that I'm familiar with that is available from user code for procedural macros.

I can write an RFC, but I'm kinda surprised you want a whole RFC for a single method on a type that is already 90% unstable. But sure, I'll write an RFC.

@petrochenkov
Copy link
Contributor

petrochenkov commented Apr 28, 2019

@mjbshaw

and I have no idea how gensym is used within the compiler.

For generating unique identifiers, for various purposes.
That's what you want from Span::unique_span more or less.
However, for many of those purposes Span::def_site should be enough.

My motivation is to use Span::unique_site in user code (procedural macros, specifically), much like I'd want to use gensym in Lisp

It would be great to describe those use cases in the RFC.

I'm kinda surprised you want a whole RFC for a single method on a type that is already 90% unstabl

I wouldn't underestimate how tricky and complex this single method is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants