ehuss
commented
4 years ago I have implemented a branch that removes --sysroot, and instead adds "options" to the --extern flag. In this case, it is --extern noprelude:alloc=/path/to/deps/liballoc.rlib. The "noprelude" option tells rustc not to add to the prelude which addresses the original concern in #40 that made us switch. It also is more careful about which crates it passes to rustc via --extern. It seems to work well.
Any objections to moving in that direction?
If that is OK, the next question I have: Should I prototype a new flag in rustc to disable crate searches in the sysroot? This would help with avoiding the dreaded "duplicate lang item" error if you have an errant extern crate for something you shouldn't have access to (and instead show E0463 or E0433 failed to resolve error). I think it might be a good idea, and would also ensure that things like rust-lld are still found. However, I recognize that it's a minor error message improvement, so may not be important enough. I'm not sure how careful rustc is about the proliferation of random flags. If that sounds ok, any opinion on the flag name? Maybe --no-sysroot-search?
alexcrichton
Ericson2314
I'm realizing now that after we've implemented
--sysrootthat we may still be susceptible races where you can depend on a sysroot crate without actually declaring that you depend on it. Let's say that https://github.com/rust-lang/wg-cargo-std-aware/issues/5 has already been implemented, and you say you only depend oncore, I think you could also depend onallocvia the following:alloc, but your crate fails to build.alloccrate, however, did actually end up finish building by the time your crate received its error.cargo buildagain.allocis linked into the sysrootextern crate alloc, now "magically works"I think the problem here is that we're giving, via
--sysroot, crates access to anything in the sysroot. Cargo doesn't actually have any control over what can be loaded from the sysroot. While this will probably only rarely come up in practice, I think we may want to strive to have Cargo have a more intrusive understanding of what crates are where in the sysroot.Assuming that #5 is implemented I think we'll have some sort of distinction between crates that have sysroot dependencies or not. For example your crate will either declare its sysroot dependencies explicitly, or you won't say anything (like all crates do today) and we'll have some default behavior (like assuming you can use up to
proc_macro). That puts us in one of two buckets:--sysroot. We instead use--externalways. This should be fine since the feature isn't implemented yet! If you're building in-Zbuild-stdmode Cargo has a path to pass, otherwise Cargo uses--extern stdto activate the name resolution logic to work the same as if--extern name=pathwas passed.--extern-sysrootflag to point to the compiled crates. This has the same name resolution logic that sysroot crates have today (wrt shadowing via macros and stuff like that).The invented
--extern-sysrootflag here would take the form--extern-sysroot name=path. In all cases Cargo would pass-L dependency=...for the sysroot, and the--externflags would configure which crates can be loaded from the sysroot. The only reason for--extern-sysrootto exist is to match the name resolution behavior of sysroot crates today since there are subtle differences. Alternatively we could fix rustc so there are no differences!