The Great Module Adventure Continues

[nox]

@matklad And then how do I notice that image_png is the png crate from crates.io?

I still don’t understand why we are deprecating extern crate when that means there will be no way for RLS to point out to what image_png is. How do I notice that image_png is just the png crate without going through hoops having to open the crate’s Cargo.toml manifest?

I know from experience that I’ve very often did such things in Servo, where we rename the cookie crate to cookie_rs because we have a cookie module. Telling VSCode to “jump to definition” with the cursor on cookie_rs will bring me to extern crate cookie as cookie_rs. How do I do this now?

[aturon]

Telling VSCode to “jump to definition” with the cursor on cookie_rs will bring me to extern crate cookie as cookie_rs. How do I do this now?

It will jump to Cargo.toml.

[jntrnr]

RLS uses the Cargo.toml via cargo rather than trying to parse and understand the syntax file. This is also how it builds and analyses more complex projects.

The removal of extern crate should not have an impact on the abilities of RLS. Jump to definition will continue to work how it does today.

[petrochenkov]

Jump to definition will continue to work how it does today.

The problem and the source of the concern is that it _doesn’t_ work today.
I’m using VSCode and neither @KalitaAlexey’s plugin nor RLS plugin can’t jump into locations in Cargo.toml.
At least the first one can jump into the lib.rs of the extern crate, RLS doesn’t do even that.

[jntrnr]

That could be. I’m just saying that this is a separate issue from the removal of extern crate or not. The RLS will use what it knows from the Cargo.toml file via cargo. The behaviour we allow for goto definition is separate and more of a dev tools team discussion on RLS functionality.

[mark-i-m]

All crates provided by Cargo.toml, --extern, or the standard distribution are treated as part of the prelude for the crate.

Hmm… does this transitively include all dependencies of dependencies? That might get a bit overwhelming for large projects.

[aturon]

does this transitively include all dependencies of dependencies

No, just the direct dependencies, i.e. things you’re able to use extern crate with today.

[steveklabnik]

I love this proposal. I agree with the “it just feels right” comment. Well done!

… however.

I just thought of one tiny snag with eliminating mod.rs. It’s not insurmountable, but something to think about.

When writing integration tests, if you want to create some sort of utilities module, you can’t make test/utils.rs, because then it tries to compile utils.rs as a test as well, and that often fails. So you use utils/mod.rs, and it works. For more, see here: https://doc.rust-lang.org/book/second-edition/ch11-03-test-organization.html#submodules-in-integration-tests

What should we do here?

[nikomatsakis]

What should we do here?

The answer is clear. Only support foo/mod.rs-style modules, not foo.rs.

</ducks>

So, that is annoying. Still, the existing situation is not great – I feel like modules from integration tests should not be all “muddled together” in a common directory.

Personally, I think it’d be nice if integration tests were, well, more like today’s modules, either tests/some_test.rs or tests/some_test/..., right? But that kind of puts us back where we started (what do we call the ...). Also, the existing behavior of ignoring directories must be accommodated, since clearly we are relying on it.

TL;DR I don’t know =) but good you raised it…

[matklad]

When writing integration tests, if you want to create some sort of utilities module

Do you want to use this utils module for a single integration test, or for several integration tests? If the former, you can now write multi-file integration tests:

test/
  foo/
    main.rs 
    utils.rs

If you want to reuse this module for several tests, you’d better to extract it into a crate and use it as a path dev-dependency. Otherwise, this module will be compiled multiple times, once per integration test, and it doesn’t feel exactly right.

[nikomatsakis]

If the former, you can now write multi-file integration tests:

That’s what I was looking for…

[steveklabnik]

Whoah when did this happen?

[matklad]

In 1.22 https://github.com/rust-lang/cargo/pull/4496/files & https://github.com/rust-lang/rust/blob/master/RELEASES.md#cargo-2.

The question is, why the docs over https://doc.rust-lang.org/cargo/reference/manifest.html do not mention it, although the source code for the docs (https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/manifest.md#the-project-layout) does (search for (optional) directories containing multi-file tests)

EDIT: nightly book is OK though EDIT2: looks like the missing docs are found, recovered, and will be installed in the legitimate place with the next relase: https://github.com/rust-lang/cargo/issues/4906

[Dylan-DPC]

Can we have a summarised post here with all the options, example for each one and reasons for/against? Makes it easier to follow and draw up a conclusion.

[nikomatsakis]

@petrochenkov let’s talk implementation for a second. Do you think there are remaining details from what @aturon described that need to be cleared up before we can implement? Do you think you’ll have time to hack on this stuff? (If not, would you be up for mentoring and/or just e-mailing me a few brief notes and I can take a stab at mentoring?)

[nikomatsakis]

I think that @aturon’s post here is still basically “the latest”.

[petrochenkov]

@nikomatsakis
I plan to work on this next.
After https://github.com/rust-lang/rust/pull/48917 lands I need to do some strategic refactoring in import resolution, because the current implementation of use my_crate as name; is a hack and contains bugs preventing, for example, putting use crate as std; into libstd prelude.
After that I’ll try to implement the fallback.

The “put everything from --extern cmdline option into the prelude” part is almost trivial and can be implemented independently at any time, but I’m not sure it’s a good idea in general and it’s also a pure extension, so I’d rather implement it as one more option under a separate feature gate for now. (I can write mentoring instructions for this part.)

[CAD97]

Interesting note: you can get something similar the way this is going today with use ::*; if people want to try out a very-suboptimal version of the always-in-scope extern crates. Do note that it also brings in your root modules as well, as you would expect.

[mark-i-m]

@Dylan-DPC This comment is the current proposal: The Great Module Adventure Continues

[nikomatsakis]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.