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

Tracking Issue for #![feature(extended_key_value_attributes)] #78835

Closed
petrochenkov opened this issue Nov 7, 2020 · 12 comments · Fixed by #83366
Closed

Tracking Issue for #![feature(extended_key_value_attributes)] #78835

petrochenkov opened this issue Nov 7, 2020 · 12 comments · Fixed by #83366
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-parser Area: The parsing of Rust source code to an AST B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-extended_key_value_attributes `#![feature(extended_key_value_attributes)] T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@petrochenkov
Copy link
Contributor

petrochenkov commented Nov 7, 2020

Implemented in #78837.

With this feature arbitrary expressions are supported in values of key-value attributes at parse time.

#[my_attr = EXPR]

Previously only unsuffixed literals and interpolated expressions ($expr) were accepted.

If the attribute in question survives expansion, then the value is still restricted to unsuffixed literals by a semantic check. This restriction may also be relaxed in the future.

@camelid camelid added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-parser Area: The parsing of Rust source code to an AST C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Nov 10, 2020
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 10, 2020
Accept arbitrary expressions in key-value attributes at parse time

Continuation of rust-lang#77271.

We now support arbitrary expressions in values of key-value attributes at parse time.
```
#[my_attr = EXPR]
```
Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted.

There are two immediate motivational cases for this:
- External doc strings (`#[doc = include_str!("my_doc.md")]`, eliminating the need in rust-lang#44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom).
- Paths (`#[namespace = foo::bar] extern "C++" { ... }`) like proposed in rust-lang#76734.

If the attribute in question survives expansion, then the value is still restricted to unsuffixed literals by a semantic check.
This restriction doesn't prevent the use cases listed above, so this PR keeps it in place for now.

Closes rust-lang#52607.
Previous attempt - rust-lang#67121.
Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455.
Tracking issue - rust-lang#78835.
@jyn514
Copy link
Member

jyn514 commented Dec 10, 2020

On the next bootstrap bump, I plan to switch the standard library from using doc(include) to doc = include_str!. Unfortunately it does need the bump to test since the syntax changed:

error: unexpected token: `include_str`
 --> library/std/src/macros.rs:7:34
  |
7 | #[cfg_attr(not(bootstrap), doc = include_str!("../../core/src/macros/panic.md"))]
  |                                  ^^^^^^^^^^^
  |
  = help: the valid syntax is `#[cfg_attr(condition, attribute, other_attribute, ...)]`
  = note: for more information, visit <https://doc.rust-lang.org/reference/conditional-compilation.html#the-cfg_attr-attribute>

@jonas-schievink jonas-schievink added T-lang Relevant to the language team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Dec 15, 2020
Thomasdezeeuw added a commit to Thomasdezeeuw/socket2 that referenced this issue Dec 20, 2020
Depends on extended_key_value_attributes, tracked here:
rust-lang/rust#78835.
@GuillaumeGomez
Copy link
Member

It doesn't work for "sub attributes". For example:

#[doc(alias = $some_expr)]
// or:
#[doc(alias = stringify!(ident))]

I'm sending a little fix so it is supported as well.

@LeSeulArtichaut LeSeulArtichaut added the F-extended_key_value_attributes `#![feature(extended_key_value_attributes)] label Dec 30, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 24, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 24, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this issue Feb 24, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 24, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 25, 2021
Use #[doc = include_str!()] in std

cc rust-lang#78835 (comment)
r? `````@jyn514`````
@ilyvion
Copy link

ilyvion commented Mar 13, 2021

I'm having a bit of a weird issue. If I compile the project with this file on Windows, everything is fine. But if I compile it on Ubuntu, I get this:

$ cargo build
   Compiling doryen-extra v0.1.0 (/home/alex/doryen-extra)
error[E0658]: arbitrary expressions in key-value attributes are unstable
  --> src/base/def_macro.rs:35:77
   |
35 | ...   define_two_property_arithmetic_struct!(@IMPL $name, $uname, $fname, stringify!($name), $field1, $field2, stringify!($field1), strin...
   |                                                                           ^^^^^^^^^^^^^^^^^
   |
  ::: src/base.rs:39:1
   |
39 | define_two_property_arithmetic_struct!(Position, UPosition, FPosition, x, y, ORIGIN, "({}, {})");
   | ------------------------------------------------------------------------------------------------- in this macro invocation
   |
   = note: see issue #78835 <https://github.com/rust-lang/rust/issues/78835> for more information
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: arbitrary expressions in key-value attributes are unstable
  --> src/base/def_macro.rs:35:77
   |
35 | ...   define_two_property_arithmetic_struct!(@IMPL $name, $uname, $fname, stringify!($name), $field1, $field2, stringify!($field1), strin...
   |                                                                           ^^^^^^^^^^^^^^^^^
   |
  ::: src/base.rs:40:1
   |
40 | define_two_property_arithmetic_struct!(Size, USize, FSize, width, height, ZERO, "{}x{}");
   | ----------------------------------------------------------------------------------------- in this macro invocation
   |
   = note: see issue #78835 <https://github.com/rust-lang/rust/issues/78835> for more information
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

I don't understand

  1. why it's only unstable on Ubuntu, but not Windows (both have rustc 1.50.0 (cb75ad5db 2021-02-10)) and
  2. what I'm supposed to do instead. I made my macro that way so that I could do #[doc = $name_str] on the value from the stringify!($name) invocation, and it was hard enough to get this working as is (#[doc = stringify!($name)] did not work), but now my workaround seems to have been made invalid, too, and I honestly don't know where to go from here...

@petrochenkov
Copy link
Contributor Author

@alexschrod
Could you make a minimized reproduction and build it with -Z macro-backtrace as the message suggests? (It will work on stable with env var RUSTC_BOOTSTRAP=1 set.)

parasyte added a commit to parasyte/pixels that referenced this issue Dec 30, 2021
- Bump MSRV for rust-lang/rust#78835
- Required by `fltk`: fltk-rs/fltk-rs#1054
parasyte added a commit to parasyte/pixels that referenced this issue Dec 30, 2021
- Bump MSRV for rust-lang/rust#78835
- Required by `fltk`: fltk-rs/fltk-rs#1054
tshepang added a commit to tshepang/post that referenced this issue Jan 3, 2022
Following is 1.53 output

    Compiling clap_derive v3.0.0
  error[E0658]: arbitrary expressions in key-value attributes are unstable
    --> /home/tshepang/.cargo/registry/src/github.com-1ecc6299db9ec823/clap_derive-3.0.0/src/lib.rs:16:10
     |
  16 | #![doc = include_str!("../README.md")]
     |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: see issue #78835 <rust-lang/rust#78835> for more information
petermetz added a commit to petermetz/cacti that referenced this issue Jan 12, 2022
The problem was that the Rust compiler version we were using
(v1.52.x) seem to have gotten outdated and it would no longer
work with wasm-pack.
To provide a fix I upgraded the base image of the container to
come with Rust v1.57.x and now the build error[1] is no longer
present and the test case is passing with the new image that was
pushed to ghcr.io.

The image tag this was pushed as is:
ghcr.io/hyperledger/cactus-rust-compiler:2022-01-12-15d4793c---fix-1646
which is now also the default tag that the RustcContainer class
uses in the test-tooling package.

[1]:
```sh
   Compiling bumpalo v3.9.1
�[38;5;9merror[E0658]: arbitrary expressions in key-value attributes are unstable
 �[38;5;12m-->
 /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/bumpalo-3.9.1/src/lib.rs:1:10
  �[38;5;12m|
�[38;5;12m1 �[38;5;12m| #![doc = include_str!("../README.md")]
  �[38;5;12m|          �[38;5;9m^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  �[38;5;12m|
  �[38;5;12m= note: see issue #78835 <rust-lang/rust#78835>
  for more information

   Compiling wasm-bindgen v0.2.78
�[38;5;9merror: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `bumpalo`
```

Fixes hyperledger-cacti#1646

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to hyperledger-cacti/cacti that referenced this issue Jan 13, 2022
The problem was that the Rust compiler version we were using
(v1.52.x) seem to have gotten outdated and it would no longer
work with wasm-pack.
To provide a fix I upgraded the base image of the container to
come with Rust v1.57.x and now the build error[1] is no longer
present and the test case is passing with the new image that was
pushed to ghcr.io.

The image tag this was pushed as is:
ghcr.io/hyperledger/cactus-rust-compiler:2022-01-12-15d4793c---fix-1646
which is now also the default tag that the RustcContainer class
uses in the test-tooling package.

[1]:
```sh
   Compiling bumpalo v3.9.1
�[38;5;9merror[E0658]: arbitrary expressions in key-value attributes are unstable
 �[38;5;12m-->
 /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/bumpalo-3.9.1/src/lib.rs:1:10
  �[38;5;12m|
�[38;5;12m1 �[38;5;12m| #![doc = include_str!("../README.md")]
  �[38;5;12m|          �[38;5;9m^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  �[38;5;12m|
  �[38;5;12m= note: see issue #78835 <rust-lang/rust#78835>
  for more information

   Compiling wasm-bindgen v0.2.78
�[38;5;9merror: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `bumpalo`
```

Fixes #1646

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
aldousalvarez pushed a commit to aldousalvarez/cactus that referenced this issue Jan 19, 2022
The problem was that the Rust compiler version we were using
(v1.52.x) seem to have gotten outdated and it would no longer
work with wasm-pack.
To provide a fix I upgraded the base image of the container to
come with Rust v1.57.x and now the build error[1] is no longer
present and the test case is passing with the new image that was
pushed to ghcr.io.

The image tag this was pushed as is:
ghcr.io/hyperledger/cactus-rust-compiler:2022-01-12-15d4793c---fix-1646
which is now also the default tag that the RustcContainer class
uses in the test-tooling package.

[1]:
```sh
   Compiling bumpalo v3.9.1
�[38;5;9merror[E0658]: arbitrary expressions in key-value attributes are unstable
 �[38;5;12m-->
 /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/bumpalo-3.9.1/src/lib.rs:1:10
  �[38;5;12m|
�[38;5;12m1 �[38;5;12m| #![doc = include_str!("../README.md")]
  �[38;5;12m|          �[38;5;9m^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  �[38;5;12m|
  �[38;5;12m= note: see issue #78835 <rust-lang/rust#78835>
  for more information

   Compiling wasm-bindgen v0.2.78
�[38;5;9merror: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `bumpalo`
```

Fixes hyperledger-cacti#1646

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
aldousalvarez pushed a commit to aldousalvarez/cactus that referenced this issue Jan 19, 2022
The problem was that the Rust compiler version we were using
(v1.52.x) seem to have gotten outdated and it would no longer
work with wasm-pack.
To provide a fix I upgraded the base image of the container to
come with Rust v1.57.x and now the build error[1] is no longer
present and the test case is passing with the new image that was
pushed to ghcr.io.

The image tag this was pushed as is:
ghcr.io/hyperledger/cactus-rust-compiler:2022-01-12-15d4793c---fix-1646
which is now also the default tag that the RustcContainer class
uses in the test-tooling package.

[1]:
```sh
   Compiling bumpalo v3.9.1
�[38;5;9merror[E0658]: arbitrary expressions in key-value attributes are unstable
 �[38;5;12m-->
 /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/bumpalo-3.9.1/src/lib.rs:1:10
  �[38;5;12m|
�[38;5;12m1 �[38;5;12m| #![doc = include_str!("../README.md")]
  �[38;5;12m|          �[38;5;9m^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  �[38;5;12m|
  �[38;5;12m= note: see issue #78835 <rust-lang/rust#78835>
  for more information

   Compiling wasm-bindgen v0.2.78
�[38;5;9merror: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `bumpalo`
```

Fixes hyperledger-cacti#1646

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Signed-off-by: aldousalvarez <aldousss.alvarez@gmail.com>
fishilico added a commit to fishilico/shared that referenced this issue May 29, 2022
libz-sys crate became incompatible with Alpine 3.13 toolchain (rust 1.47):

    error: unexpected token: `zng_prefix`
       --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/libz-sys-1.1.8/src/lib.rs:115:19
        |
    114 | extern "C" {
        |            - while parsing this item list starting here
    115 |     #[link_name = zng_prefix!(adler32)]
        |                   ^^^^^^^^^^
    ...
    241 | }
        | - the item list ends here

With Alpine 3.14 toolchain (rust 1.52):

    error[E0658]: arbitrary expressions in key-value attributes are unstable
       --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/libz-sys-1.1.8/src/lib.rs:115:19
        |
    115 |     #[link_name = zng_prefix!(adler32)]
        |                   ^^^^^^^^^^^^^^^^^^^^
        |
        = note: see issue #78835 <rust-lang/rust#78835> for more information
softpluspro12 pushed a commit to softpluspro12/rust-cdk that referenced this issue Jun 30, 2022
beta.4 introduced errors like these:

error[E0658]: arbitrary expressions in key-value attributes are unstable
 --> /Users/ericswanson/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-3.0.0-beta.4/src/lib.rs:8:10
  |
8 | #![doc = include_str!("../README.md")]
  |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #78835 <rust-lang/rust#78835> for more information

error[E0658]: use of unstable library feature 'osstring_ascii'
   --> /Users/ericswanson/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-3.0.0-beta.4/src/parse/matches/matched_arg.rs:130:19
    |
130 |                 v.eq_ignore_ascii_case(val)
    |                   ^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #70516 <rust-lang/rust#70516> for more information
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-parser Area: The parsing of Rust source code to an AST B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-extended_key_value_attributes `#![feature(extended_key_value_attributes)] T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants