regression: error[E0658]: use of unstable library feature proc_macro_totokens

[cuviper]

Two logs failed to compile sqlx-models-proc-macro:

1. https://crater-reports.s3.amazonaws.com/beta-1.84.0-4-retry2/beta-2024-12-08/reg/sql_from_models-proc-macro-0.1.2/log.txt
2. https://crater-reports.s3.amazonaws.com/beta-1.84.0-4-retry2/beta-2024-12-08/reg/sqlx-models-proc-macro-0.0.3/log.txt

[INFO] [stdout] warning: `ToTokens` is ambiguous
[INFO] [stdout]   --> src/model/mod.rs:59:6
[INFO] [stdout]    |
[INFO] [stdout] 59 | impl ToTokens for Model {
[INFO] [stdout]    |      ^^^^^^^^ ambiguous name
[INFO] [stdout]    |
[INFO] [stdout]    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
[INFO] [stdout]    = note: for more information, see issue #114095 <https://github.com/rust-lang/rust/issues/114095>
[INFO] [stdout]    = note: ambiguous because of multiple glob imports of a name in the same module
[INFO] [stdout] note: `ToTokens` could refer to the trait imported here
[INFO] [stdout]   --> src/prelude.rs:2:35
[INFO] [stdout]    |
[INFO] [stdout] 2  | pub use proc_macro::{TokenStream, *};
[INFO] [stdout]    |                                   ^
[INFO] [stdout]    = help: consider adding an explicit import of `ToTokens` to disambiguate
[INFO] [stdout] note: `ToTokens` could also refer to the trait imported here
[INFO] [stdout]   --> src/prelude.rs:4:24
[INFO] [stdout]    |
[INFO] [stdout] 4  | pub use quote::{quote, *};
[INFO] [stdout]    |                        ^
[INFO] [stdout]    = help: consider adding an explicit import of `ToTokens` to disambiguate
[INFO] [stdout] 
[INFO] [stdout] 
[INFO] [stdout] error[E0658]: use of unstable library feature `proc_macro_totokens`
[INFO] [stdout]   --> src/model/mod.rs:60:5
[INFO] [stdout]    |
[INFO] [stdout] 60 | /     fn to_tokens(&self, tokens: &mut TokenStream2) {
[INFO] [stdout] 61 | |         let name = &self.name;
[INFO] [stdout] 62 | |         let name_lowercase = &self.name_lowercase;
[INFO] [stdout] 63 | |         let columns = &self.get_columns();
[INFO] [stdout] ...  |
[INFO] [stdout] 75 | |         tokens.extend(template);
[INFO] [stdout] 76 | |     }
[INFO] [stdout]    | |_____^
[INFO] [stdout]    |
[INFO] [stdout]    = note: see issue #130977 <https://github.com/rust-lang/rust/issues/130977> for more information

So it appears to be globbing the unstable proc_macro::ToTokens before the desired quote::ToTokens.

Version it worked on

It most recently worked on: 1.83.0

Version with regression

Using rustc 1.84.0-beta.4 in crater #134138.

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged

[compiler-errors]

This was introduced by #131441. I'm not sure if it's avoidable in general given this pattern of glob imports, seems like the code was just waiting to have a glob import ambiguity :'(

[cuviper]

Also related: https://crater-reports.s3.amazonaws.com/beta-1.84.0-4-retry2/beta-2024-12-08/reg/chime-flux-proc-macro-0.3.0/log.txt

[INFO] [stdout] warning: unused import: `quote::*`
[INFO] [stdout]  --> src/lib.rs:3:5
[INFO] [stdout]   |
[INFO] [stdout] 3 | use quote::*;
[INFO] [stdout]   |     ^^^^^^^^
[INFO] [stdout]   |
[INFO] [stdout]   = note: `#[warn(unused_imports)]` on by default
[INFO] [stdout] 
[INFO] [stdout] 
[INFO] [stdout] error[E0599]: the method `to_token_stream` exists for reference `&Stmt`, but its trait bounds were not satisfied
[INFO] [stdout]    --> src/lib.rs:175:9
[INFO] [stdout]     |
[INFO] [stdout] 175 |                           s.to_token_stream()
[INFO] [stdout]     |                             ^^^^^^^^^^^^^^^
[INFO] [stdout]     |
[INFO] [stdout]    ::: /opt/rustwide/cargo-home/registry/src/index.crates.io-6f17d22bba15001f/syn-2.0.90/src/stmt.rs:18:1
[INFO] [stdout]     |
[INFO] [stdout] 18  | / ast_enum! {
[INFO] [stdout] 19  | |     /// A statement, usually ending in a semicolon.
[INFO] [stdout] 20  | |     #[cfg_attr(docsrs, doc(cfg(feature = "full")))]
[INFO] [stdout] 21  | |     pub enum Stmt {
[INFO] [stdout] ...   |
[INFO] [stdout] 37  | |     }
[INFO] [stdout] 38  | | }
[INFO] [stdout]     | |_- doesn't satisfy `Stmt: proc_macro::ToTokens`
[INFO] [stdout]     |
[INFO] [stdout]     = note: the following trait bounds were not satisfied:
[INFO] [stdout]             `Stmt: proc_macro::ToTokens`
[INFO] [stdout]             which is required by `&Stmt: proc_macro::ToTokens`
[INFO] [stdout]     = help: items from traits can only be used if the trait is in scope
[INFO] [stdout] help: trait `ToTokens` which provides `to_token_stream` is implemented but not in scope; perhaps you want to import it
[INFO] [stdout]     |
[INFO] [stdout] 1   + use quote::ToTokens;
[INFO] [stdout]     |

[jieyouxu]

This was introduced by #131441. I'm not sure if it's avoidable in general given this pattern of glob imports, seems like the code was just waiting to have a glob import ambiguity :'(

Seems like we may need to just accept that this can break code that was using glob imports in this fashion (I think this is glob-vs-glob?), unless we manage to never add things to proc_macros, which is also undesirable... I suppose we could notify the crates that broke?

Not sure what else can be done, outside of better advertisement/awareness-raising about breakages that can happen from glob-vs-glob imports between multiple imported crates?

[compiler-errors]

Yeah, but that's probably a call that's best left for T-libs-api since they could presumably opt to mitigate this breakage some other way (like renaming the trait to have fewer conflicts or something, though I don't personally think that needs to get done)

[Amanieu]

We discussed this in the libs-api meeting today. While these crates have been updated somewhat recently, we don't think they are sufficiently widely used to justify specific workarounds in the compiler/library. As several people have said, the use of glob imports here just makes the code very brittle to future library changes.

[tgross35]

Maybe Clippy could duplicate wildcard_imports to std_wildcard_imports at something other than the pedantic level. I'll open an issue for this.

In theory we could probably also allow std glob imports to be overridden by anything else, but I'm not sure we really want to promote this use.