In all cases the error is fixable with one of suggestions provided by the compiler.

That's not much given that the change affects all 2015 imports and almost every crate in existence uses imports.
So, if we want to make this change then it's quite realistic to do it through deprecation lint.

This comment has been minimized.

edited

If you remember early stages of the import reform discussion, this is exactly the "fallback from crate::foo to extern::foo in use foo to eliminate extern crate without edition breakage" variant.

I had concerns about its implementability back then and wanted to make a proof of concept implementation before choosing it, but now all the infrastructure is ready thanks to uniform paths, so the implementation can be done easily.

This comment has been minimized.

I believe these changes are sorely needed to make the module system and resolution more scrutable and reduce the number of rules since even language team members have a hard time following them.

At the same time, this is not exactly a bug-fix but rather a choice to make to simplify things and make the edition story smoother. In particular, the breakage to skeptic makes me uneasy. (actix only has a test breakage which makes it less problematic).

I am torn about this... but the amount of regressions is sufficiently small to make filing PRs to each of them possible.. and I think the ecosystem as a whole will benefit more than it suffers; so with that said, let's see what the rest of the team thinks...

This comment has been minimized.

@joshtriplett
I've just confirmed that all the regressed crates (#57745 (comment)) build successfully if the ambiguity errors are demoted to deprecation lints.
So the "breakage process" can be stretched for an arbitrary period of time.

This comment has been minimized.

edited

Technically the ambiguity errors are an "early-phase resolution + fallback" thing, so they happen on 2015 edition as well, with macro paths.

why do we consider it reasonable to break backward compatibility here?

Because it makes everyone's life easier.
Starting from users confused by edition differences and the "half there" model currently working on 2015 edition with regards to requiring extern crate, ending with people supporting these edition differences and interactions between them in the compiler / language spec.
A lint firing in corner cases seems like an ok price to pay in this case.

This comment has been minimized.

What is being proposed here is a backwards incompatible change made in the name of overall language simplicity and consistency. This kind of things is always a balancing act: on the one hand, we aim not to break existing code. On the other hand, simplifying things helps everyone in the end, and definitely may help with long-term compiler maintenance. Not to put words in their mouth, but @joshtriplett seemed to feel that this change was not worth it overall, but I think that @Centril disagreed, and others seemed a bit uncertain (these were my impressions).

One compromise that was proposed was to try and put in some form of warning and specifically request feedback from those affected -- basically defer the final decision until we've had warnings for some time and possibly heard from affected crates. @aturon called it an "extended crater run".

Ultimately, no firm conclusion was reached.

This comment has been minimized.

One compromise that was proposed was to try and put in some form of warning and specifically request feedback from those affected -- basically defer the final decision until we've had warnings for some time and possibly heard from affected crates.

I suggest to specifically:

Report the ambiguity errors as warnings.

Fall back to extern crates, but emit a feature gate error if the fallback actually happens.

The final (positive) decision in that case would be removal of the feature gate, and the final negative decision would be removal of the fallback perhaps ambiguity warnings.

This comment has been minimized.

I also think I haven't properly answered the question "would this change make sense in isolation, regardless of breakage and cross-edition concerns (?)".

The answer is that if getting rid of extern crate items is a worthwhile goal (and it seems it is, because this is the direction in which 2018 edition moved), then it's certainly a worthwhile goal because this fallback gives exactly the "no extern crate needed" effect on 2015 edition.

This comment has been minimized.

On Thu, Jan 24, 2019 at 01:23:27PM -0800, Vadim Petrochenkov wrote:
The answer is that if getting rid of `extern crate` items is a worthwhile goal (and it seems it is, because this is the direction in which 2018 edition moved), then it's certainly a worthwhile goal because this fallback gives exactly the "no `extern crate` needed" effect on 2015 edition.

I don't think the goal should be "get rid of extern crate", it should be
"get rid of extern crate in the 2018 edition".

816: Prelude & Edition 2015 import resolution r=matklad a=flodiebold
I implemented the prelude import, but it turned out to be useless without being able to resolve any of the imports in the prelude 😅 So I had to add some edition handling and handle 2015-style imports (at least the simplified scheme proposed in rust-lang/rust#57745). So now finally `Option` resolves 😄
One remaining problem is that we don't actually know the edition for sysroot crates. They're currently hardcoded to 2015, but there's already a bunch of PRs upgrading the editions of various rustc crates, so we'll have to detect the edition somehow, or just change the hardcoding to 2018 later, I guess...
~Also currently missing is completion for prelude names, though that shouldn't be hard to add. And `Vec` still doesn't resolve, so I need to look into that.~
Co-authored-by: Florian Diebold <flodiebold@gmail.com>

816: Prelude & Edition 2015 import resolution r=matklad a=flodiebold
I implemented the prelude import, but it turned out to be useless without being able to resolve any of the imports in the prelude 😅 So I had to add some edition handling and handle 2015-style imports (at least the simplified scheme proposed in rust-lang/rust#57745). So now finally `Option` resolves 😄
One remaining problem is that we don't actually know the edition for sysroot crates. They're currently hardcoded to 2015, but there's already a bunch of PRs upgrading the editions of various rustc crates, so we'll have to detect the edition somehow, or just change the hardcoding to 2018 later, I guess...
~Also currently missing is completion for prelude names, though that shouldn't be hard to add. And `Vec` still doesn't resolve, so I need to look into that.~
Co-authored-by: Florian Diebold <flodiebold@gmail.com>

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.