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

Establish stabilization path for macro_rules feature #17895

Closed
brson opened this issue Oct 9, 2014 · 5 comments
Closed

Establish stabilization path for macro_rules feature #17895

brson opened this issue Oct 9, 2014 · 5 comments
Milestone

Comments

@brson
Copy link
Contributor

brson commented Oct 9, 2014

macro_rules needs to be stabilized before general plugins. At the least we can just put these under a different feature.

@pnkfelix
Copy link
Member

pnkfelix commented Oct 9, 2014

As the description says, it is very likely we are going to want to allow use of macro_rules! in the stable release channel. (See #16678 )

But there are a number of details that remain to be resolved. For example:

  • Will macro export also be made "stable" ?

@pnkfelix pnkfelix changed the title Allow macro_rules macros to be exported without the phase feature Establish stabilization path for macro_rules feature Oct 9, 2014
@pnkfelix
Copy link
Member

pnkfelix commented Oct 9, 2014

Assigning P-backcompat-lang, 1.0.

(This issue is still quite open-ended; much remains to be resolved. but we want to ensure we track the work that needs to be done here.)

@pnkfelix pnkfelix added this to the 1.0 milestone Oct 9, 2014
@aturon
Copy link
Member

aturon commented Nov 4, 2014

@kmcallister has some thoughts here.

@alexcrichton
Copy link
Member

This is now finished!

cc #20482
cc #20563

@aturon
Copy link
Member

aturon commented Jan 8, 2015

I believe this is now complete. Nominating for closure.

lnicola pushed a commit to lnicola/rust that referenced this issue Aug 29, 2024
…-keyword, r=Veykril

fix: Properly account for editions in names

This PR touches a lot of parts. But the main changes are changing `hir_expand::Name` to be raw edition-dependently and only when necessary (unrelated to how the user originally wrote the identifier), and changing `is_keyword()` and `is_raw_identifier()` to be edition-aware (this was done in rust-lang#17896, but the FIXMEs were fixed here).

It is possible that I missed some cases, but most IDE parts should properly escape (or not escape) identifiers now.

The rules of thumb are:

 - If we show the identifier to the user, its rawness should be determined by the edition of the edited crate. This is nice for IDE features, but really important for changes we insert to the source code.
 - For tests, I chose `Edition::CURRENT` (so we only have to (maybe) update tests when an edition becomes stable, to avoid churn).
 - For debugging tools (helper methods and logs), I used `Edition::LATEST`.

Reviewing notes:

This is a really big PR but most of it is mechanical translation. I changed `Name` displayers to require an edition, and followed the compiler errors. Most methods just propagate the edition requirement. The interesting cases are mostly in `ide-assists`, as sometimes the correct crate to fetch the edition from requires awareness (there may be two). `ide-completions` and `ide-diagnostics` were solved pretty easily by introducing an edition field to their context. `ide` contains many features, for most of them it was propagated to the top level function and there the edition was fetched based on the file.

I also fixed all FIXMEs from rust-lang#17896. Some required introducing an edition parameter (usually not for many methods after the changes to `Name`), some were changed to a new method `is_any_identifier()` because they really want any possible keyword.

Fixes rust-lang#17895.
Fixes rust-lang#17774.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants