Future incompatibility with Rust RFC 3373: Avoid non-local definitions in functions

[Urgau]

Rust RFC 3373: Avoid non-local definitions in functions was accepted and it's implementation at rust-lang/rust#120393 found that this crate would be affected by it.

To be more precise users of this crate would be affected by it, in the form of a warn-by-default lint: non_local_definitions. This is because the derive macros from this crate use impl in a local context, const _DERIVE_Display_FOR_???:

displaydoc/src/expand.rs

Lines 22 to 25 in f0b62a5

	let dummy_const = format_ident!("_DERIVE_Display_FOR_{}", input.ident);
	Ok(quote! {
	#[allow(non_upper_case_globals, unused_attributes, unused_qualifications)]
	const #dummy_const: () = {

Fortunately a simple fix exist for this crate, by using a const-anon instead of named one:

-    let dummy_const = format_ident!("_DERIVE_Display_FOR_{}", input.ident);
     Ok(quote! {
         #[allow(non_upper_case_globals, unused_attributes, unused_qualifications)]
-        const #dummy_const: () = {
+        const _: () = {

---

I would suggest applying some form of the patch above as well as releasing a patch version of this crate, as to have a fix available for users as soon as possible.

cc @yaahc

[rnbguy]

The RFC impl is merged in the latest nightly. displaydoc dependent nighly crates are getting the warning now.

[Manishearth]

Does that patch actually work? My understanding is that displaydoc does this scoping so that it can have some local types and impls

[Urgau]

Yes, it should work. We do (in rustc) special case const-anon to not lint, given the widespread usage of that pattern.

[Manishearth]

But it seems like that just hoists all the definitions to the outer scope? So they'll clash with each other?

[Manishearth]

This should work: #49

[kpreid]

But it seems like that just hoists all the definitions to the outer scope? So they'll clash with each other?

An anonymous const item with a block expression still introduces a new scope just like a named const. (In fact, it's the block expression that's doing all the work; the const _: () = is just a way to put a const-evaluated expression in a context that accepts items.)

[Manishearth]

@kpreid hmm, in that case the error message for this future incompat lint seems incorrect?

rust-lang/rust#120363 (comment)