Macros show up in rust docs when pub use'd

[jrobsonchase]

From my understanding, macro re-export is unstable and feature-gated, but macros are showing up in rust docs when, for example, I have:

#[macro_use]
extern crate log;
pub use log::*;

Which would seem to imply that they should be accessible from other crates, even though they can't.

rustc version:
rustc 1.17.0-nightly (134c4a0 2017-03-20)

cc @jseyfried

[jseyfried]

@Pursuit92
use with macros should be feature-gated, but glob imports can bypass the feature gate (this is a bug -- the feature gate only got implemented for single imports).

That being said, we want to stabilize #![feature(use_extern_macros)] as is this cycle, so I don't think this is worth gating this gating today and breaking procedural-masquerade.

[brson]

Apparently this allows stable reexport of macro_rules macros, not on purpose. Seems like this should be addressed.

[SimonSapin]

We have been shipping for several months code that relies on stable reexporting of macro_rules macros. Please don’t break this now.

[jrobsonchase]

I disagree with the notion that we shouldn't fix bugs just because there might be code that relies on the incorrect behavior. That's how we end up with windows-esque insanity where bugs from back in the DOS days get forward ported rather than fixed to actually match the spec.

[SimonSapin]

there might be code

There definitely is, this is not theoretical.

the incorrect behavior

This behavior is not incorrect: it is working perfectly as intended. The only part that wasn’t intended is making that behavior available on the stable channel yet.

There is also no other way to achieve this on today’s stable rust, so "fixing" this accidental stabilization would be a regression in functionality.

[jrobsonchase]

There was also some code in existence (some of mine included) that relied on Go's built-in hashmaps being consistently ordered between separate range iterations, even though the spec explicitly said that iteration order was not guaranteed and should be considered random. That doesn't mean, IMO, that it was a mistake to change iteration order to truly be random and break everything that depended on it. They were just wrong in their reliance on an implementation detail.

And there are plenty of things that aren't possible in stable rust. The fact that something was made possible by mistake is no reason to get stuck with a feature design that may or may not be how it would eventually end up.

[jseyfried]

@jechas01

no reason to get stuck with a feature design that may or may not be how it would eventually end up.

There's wide agreement that this is how it will end up, so there's very little risk of this. We almost stabilized use_extern_macros a couple of release cycles ago but wanted to avoid advertising it until declarative macros 2.0 was further along (we could re-evaluate now that declarative macros 2.0 is landed behind a feature gate).

[nikomatsakis]

I don't really know what's going on. @jseyfried -- what is your recommended course of action here?

[jseyfried]

Recommended course of action is to stabilize #![feature(use_extern_macros)], but there's no hurry.

[nikomatsakis]

Recategorizing as a @rust-lang/t-dev-tools-docs issue, since this appears to be a rustdoc limitation, though I think @jseyfried's recommendation (that we stabilize the underlying feature) may be wise. @jseyfried -- what is the relevant tracking issue?

[arielb1]

See #40768 (comment)

Looks like something was accidentally stabilized. I bet it's common-law-stable by now.

[nikomatsakis]

Er, I take it back, sorry dev-tools-doc team =)

[aturon]

Lang team discussed in meeting. Conclusion was: we don't want to break code working today, and would prefer to push toward stabilization of re-exports. @withoutboats will take action on the applicable tracking issue.

[jseyfried]

Relevant tracking issue is #35896.

[jrobsonchase]

No longer relevant as of the stable 1.30 release, closing!