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

use super::* importing private members from parent module #38176

Closed
sgrif opened this issue Dec 5, 2016 · 6 comments
Closed

use super::* importing private members from parent module #38176

sgrif opened this issue Dec 5, 2016 · 6 comments
Assignees
Labels
P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@sgrif
Copy link
Contributor

sgrif commented Dec 5, 2016

Reproduction script: https://is.gd/qvbF0b

This code compiles on stable and beta but fails to compile on nightly. use super::* previously did not include private members. On nightly it is reported that "Foo is ambiguous"

@bluss bluss added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Dec 5, 2016
@bluss
Copy link
Member

bluss commented Dec 5, 2016

It's an intentional change, but everything that makes stable code stop compile is classed as a regression initially.

@sgrif
Copy link
Contributor Author

sgrif commented Dec 5, 2016

Figured as much. I believe technically this is a "minor breaking change" since code can be forwards compatibly changed to handle this by not using glob imports, right? Is it still a regression in that case? Either way a release where this warns instead of erroring would definitely be nice.

@jseyfried
Copy link
Contributor

@sgrif right, there can only be a regression when these conditions are met.

We landed this change #37127 without a warning cycle because Crater found no breakage. It would be feasible to implement a warning cycle as detailed in #35120 (comment).

cc @nrc

@sgrif
Copy link
Contributor Author

sgrif commented Dec 6, 2016

As an aside, I don't think that Crater finding no breakage should be used as justification for skipping warning cycles. It does not examine all available Rust code, or even all code on crates.io

@jseyfried jseyfried self-assigned this Dec 8, 2016
@nikomatsakis
Copy link
Contributor

Discussed in @rust-lang/compiler meeting. Indeed some fallout from these changes was expected but a warning cycle is still appropriate. The only reason to skip a warning cycle is supposed to be if a warning cycle is technically infeasible -- in which case we are to use crater to make a best effort to have all affected crates get updated beforehand.

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Dec 8, 2016
@nikomatsakis
Copy link
Contributor

triage: P-high

Specifically, high priority to add a warning cycle.

@rust-highfive rust-highfive added the P-high High priority label Dec 8, 2016
ustulation added a commit to ustulation/cargo-prune that referenced this issue Dec 15, 2016
This will pass build on stable but fail current nightly due to rust-lang/rust#38176 . So we are just checking if doc.rs generates stuff if nightly fails but stable passes
ustulation added a commit to ustulation/cargo-prune that referenced this issue Dec 15, 2016
This will pass build on stable but fail current nightly due to rust-lang/rust#38176 . So we are just checking if doc.rs generates stuff if nightly fails but stable passes
bors added a commit that referenced this issue Dec 20, 2016
resolve: change most backwards incompatible ambiguity errors to `legacy_imports` warnings

Fixes #38176.
r? @nrc or @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants