Skip to content

Conversation

SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Jun 8, 2018

As proposed in #51418.


Update: Per discussion below this PR also needs to add a warning for 2015 edition code that would break with the new prelude. Help wanted: any ideas how to make that happen?

@rust-highfive
Copy link
Contributor

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 8, 2018
@SimonSapin SimonSapin added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. WG-epoch Working group: Epoch (2018) management F-rust_2018_preview `#![feature(rust_2018_preview)]` labels Jun 8, 2018
@leoyvens
Copy link
Contributor

leoyvens commented Jun 8, 2018

Yay more prelude. But how will the decision be made for proposed extensions such as: Debug, Display, HashMap, HashSet, FromIterator.

@killercup
Copy link
Member

killercup commented Jun 8, 2018

I'm not sure if we rustfix can easily fix errors like hyperium/h2#251 to migrate us to the new prelude.

I think we can, in theory, write lint to the rust-2018-compatibility group that changes calls to methods that become ambiguous to their fully qualified form. But I'd rather hear from @Manishearth who has way more experience with this and can better judge the horrors edge cases we might run into.

@SimonSapin SimonSapin added the E-help-wanted Call for participation: Help is requested to fix this issue. label Jun 9, 2018
@SimonSapin
Copy link
Contributor Author

@leodasvacas I think that a decision for each of these needs to be made on a case-by-case basis, and not necessarily in this PR.

@killercup I just checked https://rust-lang.github.io/rfcs/2052-epochs.html#a-broad-policy-on-epoch-changes and having rustfix automate the transition would be nice to have but per the RFC it is a requirement that code that would break warns in the previous edition. Unfortunately I don’t know how to go about implementing that warning…

@Manishearth
Copy link
Member

Lint feels a bit tricky to handle. Unsure what edge cases exist, though, so it might not be that tricky.

@@ -42,6 +42,7 @@ error[E0573]: expected type, found variant `Ok`
LL | fn foo() -> Ok {
| ^^ not a type
|
= help: there is an enum variant `std::prelude::rust2018::Ok`, try using `std::prelude::rust2018`?
= help: there is an enum variant `std::prelude::v1::Ok`, try using `std::prelude::v1`?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noticed this terrible suggestion. std::prelude::v1 is not an enum!

@pietroalbini
Copy link
Member

Ping from triage! What's the status on this?

@SimonSapin
Copy link
Contributor Author

This is blocked on additional implementation work (a warning on 2015-edition code that would break in the 2018 edition) that I don’t know how to do… or deciding an exception for this “hard requirement” stated in the RFC.

@SimonSapin
Copy link
Contributor Author

Closing for now to make triage easier. This is still tracked at #51418.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-help-wanted Call for participation: Help is requested to fix this issue. F-rust_2018_preview `#![feature(rust_2018_preview)]` S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. WG-epoch Working group: Epoch (2018) management
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants