file not found for module montgomery

[ghost]

|
15 | pub mod montgomery;
| ^^^^^^^^^^
|
= help: name the file either arithmetic/montgomery.rs or arithmetic/montgomery/mod.rs inside the directory "/home/sackery/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic"

[andrewtj]

0.11 does include that file, have you per-chance done something that would have removed it? If not what platform, Rust version, etc are you using and can you provide steps to reproduce the problem?

[thomashoneyman]

Same error here. Versions:

rustc 1.24.0-nightly
ring 0.11.0

I'm running on MacOS 10.13.2

error[E0583]: file not found for module `montgomery`
  --> /.../.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic/arithmetic.rs:15:9
   |
15 | pub mod montgomery;
   |         ^^^^^^^^^^
   |
   = help: name the file either arithmetic/montgomery.rs or arithmetic/montgomery/mod.rs inside the directory "/.../.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic"

error: aborting due to previous error

error: Could not compile `ring`.

This happens on a fresh git clone / install using the following Cargo.toml:

[package]
name = "x"
version = "0.1.0"

[dependencies]
dotenv = "0.10"
csv = "1.0.0-beta.5"
rocket = "0.3"
rocket_codegen = "0.3"
multipart = "0.13"
serde = "1"
serde_derive = "1"
url = "1.5"

[dependencies.rocket_contrib]
version = "*"
default-features = false
features = ["json", "handlebars_templates"]

[workspace]

[thomashoneyman]

Updated my comment above with the Cargo file @andrewtj.

This branch fails to build with the versions posted above; you should be able to clone / see the error:
https://github.com/thomashoneyman/seo-utilities/tree/ci

Edit:
I hadn't pushed the most recent local changes yet. Branch contains them now.

[andrewtj]

Ta, on macOS 10.12.6 it works with nightly-2017-12-21 but not nightly-2017-12-22.

[thomashoneyman]

I see. It does build correctly on the latest nightly in the Docker image supported at rustlang/rust:nightly.

[thomashoneyman]

@andrewtj Are you aware of a way to set the specific nightly for a project?

[ghost]

why don't follow rust standard module contract?!
use mod.rs not #path[...]

[briansmith]

why don't follow rust standard module contract?!
use mod.rs not #path[...]

Because the old mod.rs naming scheme is terrible. rust-lang/rust#46531 implements a new path scheme that we'll switch to when it reaches stable rust.

[briansmith]

Ta, on macOS 10.12.6 it works with nightly-2017-12-21 but not nightly-2017-12-22.

Sounds like a regression in rustc nightly, probably related to rust-lang/rust#46531 or a closely-related change.

[ghost]

I just manually add #[path] on each mod on nightly-2017-12-21.

[andrewtj]

@thomashoneyman rustup override can be used to set a toolchain for a directory. Running rustup install nightly-2017-12-21 and then from your project dir rustup override set nightly-2017-12-21 should get you going again.

[thomashoneyman]

@andrewtj Yep, that's working for me. However, I'm already set to nightly 12-21 by default and that fails; moving to 12-20 works. Thanks for the help.

[cramertj]

This is rust-lang/rust#46936 and was caused by rust-lang/rust#46531. I responded here. Apologies for the surprise breakage! Would you accept a PR fixing this issue? Whether or not we roll back rust-lang/rust#46531, rust-lang/rust#37872 will be made a hard error in the near future, which will break ring.

Edit: opened #599 to address this.

[briansmith]

This is rust-lang/rust#46936 and was caused by rust-lang/rust#46531. I responded here. Apologies for the surprise breakage! Would you accept a PR fixing this issue? Whether or not we roll back rust-lang/rust#46531, rust-lang/rust#37872 will be made a hard error in the near future, which will break ring.

Edit: opened #599 to address this.

Please stabilize the new path search rules before breaking stuff using the old path rules. Then we'll just switch to the new path system. In the meantime, please keep the way ring is doing things working. We've been doing things this non-optimal way with #[path] in ring for a while we wait for the new path search rules, and we did it this way specifically to advocate (with our feet, so to speak) for the new path rules, so that we don't have to name every other file mod.rs.

[cramertj]

Please stabilize the new path search rules before breaking stuff using the old path rules.

We're not breaking the old path rules-- the old rules are (and will continue to be) intact. The fact that what you're doing in this crate ever worked was the result of a bug-- it was never a supported structure. mod statements were only ever officially supported in mod.rs and lib.rs files. In order to make the new module system features work, this bug was fixed (following a year-long warning period, concluding with a deny-by-default phase where this warning became an error).

It's possible that we can come up with a way to allow both the bug used in this crate and the new feature simultaneously. However, Rust cannot offer stability guarantees for crates allowing future-compatibility errors. These errors are warnings intended to offer crate authors the time to fix their crates before breakage occurs. Please accept #599, which changes ring to use the only currently supported directory structure. When the non_modrs_mods feature stabilizes, you can switch to use that instead.

[briansmith]

Let's just wait a week or two and see if this change gets rolled back, first.

[SergioBenitez]

@briansmith Please accept the PR sooner rather than later and backport to 0.11. It sounds like this is intended breakage with a fair warning period that was intentionally ignored by ring. What's more, once non_modrs_mods stabilizes, you can easily migrate to the structure you'd like without stability issues. This is breaking Rocket on the latest nightlies (rwf2/Rocket#513); waiting a week or two is a long time.

[briansmith]

I'll come back to this after I clear my backlog.

[briansmith]

This is fixed in 0.13.0-alpha.