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.

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

proc_macro does not have a constructor for byte literals #71358

Closed
CAD97 opened this issue Apr 20, 2020 · 4 comments
Closed

proc_macro does not have a constructor for byte literals #71358

CAD97 opened this issue Apr 20, 2020 · 4 comments
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@CAD97
Copy link
Contributor

CAD97 commented Apr 20, 2020

We have Literal::string(&str) for string literals, Literal::character(char) for character literals, and Literal::byte_string(&[u8]) for byte string literals, but no Literal::byte_character(u8) for byte literals.
@jonas-schievink jonas-schievink added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Apr 20, 2020
@Aaron1011 Aaron1011 added the A-proc-macros Area: Procedural macros label May 21, 2020
@wycats
Copy link
Contributor

wycats commented Oct 7, 2021

This seems important. Is there something we're missing?

@CAD97
Copy link
Contributor Author

CAD97 commented Oct 8, 2021

Byte literal chars are "just" sugar for u8, so I assume you'd be quite hard pressed to find a location where using one or the other is important (modulo a proc macro to specifically check for that). Additionally, you can always use <TokenStream as FromStr>

@wycats
Copy link
Contributor

wycats commented Nov 16, 2021 •
edited
Loading

@CAD97's comments notwithstanding, I still don't get why this constructor is missing. It makes it impossible to construct a token stream that is a high-fidelity representation of the input (which can have implications for error message). It also has implications for round tripping.

@Emilgardis Emilgardis mentioned this issue Jun 16, 2023
Merged
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 7, 2023
@bors
Auto merge of rust-lang#112711 - Emilgardis:lit_byte_char, r=dtolnay
45bc58c 
implement Literal::byte_character

without this, the only way to create a `LitKind::Byte` is by
doing `"b'a'".parse::<Literal>()`, this solves that by enabling
`Literal::byte_character(b'a')`

cc rust-lang#71358

I think this could be done as a FCP, but I've made it as a unstable feature for now until that's decided.
The tracking issue is currently wrong.
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 8, 2023
@bors
Auto merge of rust-lang#112711 - Emilgardis:lit_byte_char, r=dtolnay
679b53f 
implement Literal::byte_character

without this, the only way to create a `LitKind::Byte` is by
doing `"b'a'".parse::<Literal>()`, this solves that by enabling
`Literal::byte_character(b'a')`

cc rust-lang#71358

I think this could be done as a FCP, but I've made it as a unstable feature for now until that's decided.
The tracking issue is currently wrong.
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 23, 2023
@bors
Auto merge of rust-lang#112711 - Emilgardis:lit_byte_char, r=dtolnay
acfb46d 
implement Literal::byte_character

without this, the only way to create a `LitKind::Byte` is by
doing `"b'a'".parse::<Literal>()`, this solves that by enabling
`Literal::byte_character(b'a')`

cc rust-lang#71358

The tracking issue is rust-lang#115268
@Emilgardis
Copy link
Contributor

This has been added as Literal::byte_character behind #![feature(proc_macro_byte_character)], tracked in #115268

@dtolnay dtolnay closed this as completed Sep 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@wycats @Aaron1011 @Emilgardis @jonas-schievink @dtolnay @CAD97