compiler: Make Externally Implementable Item (eii) macros "semiopaque"

[Enselic]

Otherwise eiis defined by std will produce large amounts of missing stability attribute errors. This problem is not eii specific, as can be seen in #146993 and which is demonstrated in #151022.

As can be seen with

$ git grep rustc_macro_transparency
compiler/rustc_arena/src/lib.rs:#[rustc_macro_transparency = "semiopaque"]
[...]

it is very common for macros to use "semiopaque".

r? @jdonszelmann

Tracking issue: #125418

Needed for: #150588

[jdonszelmann]

what does opaque/semiopaque exactly mean? like what effect does that have? Is there a nice reference somewhere?

[jdonszelmann]

@rustbot author

[Enselic]

@jdonszelmann Hopefully the in-tree docs can help?

rust/compiler/rustc_span/src/hygiene.rs

Lines 182 to 200 in 3bdf45f

	/// A property of a macro expansion that determines how identifiers
	/// produced by that expansion are resolved.
	#[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Hash, Debug, Encodable, Decodable)]
	#[derive(HashStable_Generic)]
	pub enum Transparency {
	/// Identifier produced by a transparent expansion is always resolved at call-site.
	/// Call-site spans in procedural macros, hygiene opt-out in `macro` should use this.
	Transparent,
	/// Identifier produced by a semi-opaque expansion may be resolved
	/// either at call-site or at definition-site.
	/// If it's a local variable, label or `$crate` then it's resolved at def-site.
	/// Otherwise it's resolved at call-site.
	/// `macro_rules` macros behave like this, built-in macros currently behave like this too,
	/// but that's an implementation detail.
	SemiOpaque,
	/// Identifier produced by an opaque expansion is always resolved at definition-site.
	/// Def-site spans in procedural macros, identifiers from `macro` by default use this.
	Opaque,
	}

Also, this seems to be the most important place for where the difference of the variants matter (but I don't understand the code myself):

rust/compiler/rustc_span/src/hygiene.rs

Lines 605 to 619 in 3bdf45f

	// Evaluate opaque and semi-opaque versions of the new syntax context.
	let (opaque, opaque_and_semiopaque) = match transparency {
	Transparency::Transparent => (parent_opaque, parent_opaque_and_semiopaque),
	Transparency::SemiOpaque => (
	parent_opaque,
	// Will be the same as `ctxt` if the expn chain contains only (semi-)opaques.
	self.alloc_ctxt(parent_opaque_and_semiopaque, expn_id, transparency),
	),
	Transparency::Opaque => (
	// Will be the same as `ctxt` if the expn chain contains only opaques.
	self.alloc_ctxt(parent_opaque, expn_id, transparency),
	// Will be the same as `ctxt` if the expn chain contains only (semi-)opaques.
	self.alloc_ctxt(parent_opaque_and_semiopaque, expn_id, transparency),
	),
	};

I personally find the discussion that starts here interesting.

But for me it really boils down to:

• doing this makes errors go away
• the same thing is done to a lot of other macros already
• we are making changes to an unstable feature and don't have to get everything perfect on the first try