Stream: t-compiler/major changes

Topic: Make it easier to build the standard libr… compiler-team#394


triagebot (Dec 29 2020 at 16:26, on Zulip):

A new proposal has been announced: Make it easier to build the standard library #394. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.

Joshua Nelson (Dec 29 2020 at 16:27, on Zulip):

@simulacrum the bot works :tada:

Joshua Nelson (Dec 29 2020 at 16:34, on Zulip):

so, originally I expected 2. to be the controversial part of this proposal, but after looking at the discussion in https://github.com/rust-lang/rust/pull/76533 again it seems there's concerns about both parts

Joshua Nelson (Dec 29 2020 at 16:35, on Zulip):

@Eric Huss do you mind expanding on why splitting library/ into a separate workspace means rustc-dep-of-std is necessary (and more necessary than it is now)?

bjorn3 (Dec 29 2020 at 16:38, on Zulip):

What would be the benefit of using git subtree? Just cd'ing to library/ should be enough for most users.

Joshua Nelson (Dec 29 2020 at 16:38, on Zulip):

cloning the rust-lang/rust repository takes a while

Joshua Nelson (Dec 29 2020 at 16:39, on Zulip):

and you have to know that the build process for the standard library is different than the compiler; the main issue is that cargo build in the top level of rust-lang/rust can never work

Joshua Nelson (Dec 29 2020 at 16:39, on Zulip):

but I think cargo build in rust-lang/library is feasible

Joshua Nelson (Dec 29 2020 at 16:40, on Zulip):

cc @Laurențiu Nicola though, you suggested the subtree

bjorn3 (Dec 29 2020 at 16:40, on Zulip):

Most of the time of cloning is cloning the submodules, which isn't necessary except for the library/stdarch and library/backtrace submodules.

Joshua Nelson (Dec 29 2020 at 16:41, on Zulip):

ah ok I see - it's necessary now because of the unified workspace, but if the workspace were split x.py could be smarter about it

bjorn3 (Dec 29 2020 at 16:42, on Zulip):

Is it allowed to have .gitmodules in a subdirectory by the way?

Joshua Nelson (Dec 29 2020 at 16:42, on Zulip):

/me searches google

Laurențiu Nicola (Dec 29 2020 at 16:42, on Zulip):

I think so, but it's weird. I remember it makes git submodule act weirdly.

Joshua Nelson (Dec 29 2020 at 16:42, on Zulip):

if it's not, we could consider making stdarch and backtrace subtrees too

Joshua Nelson (Dec 29 2020 at 16:44, on Zulip):

(personally I find subtree a lot easier to understand than submodules)

bjorn3 (Dec 29 2020 at 16:46, on Zulip):

Stdarch has an 8.2MB .git dir.

Joshua Nelson (Dec 29 2020 at 16:47, on Zulip):

you'd have to download that anyway with submodules though, right?

Pietro Albini (Dec 29 2020 at 16:49, on Zulip):

there are cases where submodules aren't needed tho

bjorn3 (Dec 29 2020 at 16:49, on Zulip):

arm-intrinsics.html and x86-intel.xml are 21.8MB together.

Pietro Albini (Dec 29 2020 at 16:49, on Zulip):

(mostly on CI -- which doesn't use git submodule -- and when you need to interact with the commit history)

Joshua Nelson (Dec 29 2020 at 17:04, on Zulip):

Pietro Albini said:

(mostly on CI -- which doesn't use git submodule -- and when you need to interact with the commit history)

how does CI build the compiler without using x.py? x.py runs git submodule

Joshua Nelson (Dec 29 2020 at 17:05, on Zulip):

and I'd be shocked to see anyone using the git history without running x.py at least once

Joshua Nelson (Dec 29 2020 at 17:09, on Zulip):

anyway, far bigger than any of those is LLVM:

1.1G    .git/modules/src/llvm-project
Joshua Nelson (Dec 29 2020 at 17:09, on Zulip):

and that would go away completely with a subtree scheme

bjorn3 (Dec 29 2020 at 17:14, on Zulip):

Don't use a subtree for LLVM!!! That will add the full 1.1GB to the rust-lang/rust repo itself.

Joshua Nelson (Dec 29 2020 at 17:14, on Zulip):

haha, no that's not what I meant

Joshua Nelson (Dec 29 2020 at 17:14, on Zulip):

if library/ is a subtree, then cloning rust-lang/library doesn't require cloning the llvm submodule

bjorn3 (Dec 29 2020 at 17:16, on Zulip):

It doesn't anyway. It is x.py that clones it. It can easily avoid doing this if you only want to compile libstd. In fact it already avoids it when using prebuilt llvm or when you don't include LLVM in the codegen-backends key of config.toml.

Joshua Nelson (Dec 29 2020 at 17:17, on Zulip):

Hmm, ok - if cargo build works on libstd, you never have to run x.py

Joshua Nelson (Dec 29 2020 at 17:19, on Zulip):

note that this doesn't work currently because of the unified workspace:

error: failed to read `/home/joshua/src/rust/rust2/src/tools/rust-installer/Cargo.toml`
Joshua Nelson (Dec 29 2020 at 17:21, on Zulip):

oh excellent, but on https://github.com/rust-lang/rust/pull/76533 it does work except for stdarch and version mismatches

bjorn3 (Dec 29 2020 at 17:22, on Zulip):

I don't remember when it was added, but we should now need the library/backtrace submodule too.

Joshua Nelson (Dec 29 2020 at 17:22, on Zulip):

yeah, let me rebase it

bjorn3 (Dec 29 2020 at 17:24, on Zulip):

You should probably copy the Cargo.lock of the commit you rebase on top of and use it as both Cargo.lock and library/Cargo.lock for the branch. cargo build should then remove all unnecessary entries while keeping all versions intact.

Joshua Nelson (Dec 29 2020 at 17:25, on Zulip):

for now I regenerated the file, I can fix it up later

Joshua Nelson (Dec 29 2020 at 17:26, on Zulip):

just want to see if this can work

Joshua Nelson (Dec 29 2020 at 17:28, on Zulip):

ok yes, after rebasing https://github.com/rust-lang/rust/pull/76533 and running git submodule update library/{backtrace,stdarch}, cargo +nightly build works from library/test without going through x.py :)

cuviper (Dec 29 2020 at 17:29, on Zulip):

Doesn't std use src/llvm-project/libunwind?

cuviper (Dec 29 2020 at 17:29, on Zulip):

At least optionally

Joshua Nelson (Dec 29 2020 at 17:30, on Zulip):

I see feature = llvm-libunwind, but I'm ok with that just not working out of tree

bjorn3 (Dec 29 2020 at 17:30, on Zulip):

Yes, https://github.com/rust-lang/rust/blob/d9a105fdd46c926ae606777a46dd90e5b838f92f/library/unwind/build.rs#L138

bjorn3 (Dec 29 2020 at 17:31, on Zulip):

There are cases where it is not optional like linux + musl, fuchsia and fortanix.

Joshua Nelson (Dec 29 2020 at 17:31, on Zulip):

if you try to enable it the error isn't great but it's not awful either:

  running: "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-I" "../../src/llvm-project/libunwind/include" "-std=c99" "-std=c++11" "-nostdinc++" "-fno-exceptions" "-fno-rtti" "-fstrict-aliasing" "-funwind-tables" "-fvisibility=hidden" "-D__LITTLE_ENDIAN__=1" "-D_LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS" "-o" "/home/joshua/.local/lib/cargo/target/debug/build/unwind-aac1f3c9ddb7d19f/out/../../src/llvm-project/libunwind/src/Unwind-EHABI.o" "-c" "../../src/llvm-project/libunwind/src/Unwind-EHABI.cpp"
  cargo:warning=c++: error: ../../src/llvm-project/libunwind/src/Unwind-EHABI.cpp: No such file or directory
  cargo:warning=c++: fatal error: no input files
  cargo:warning=compilation terminated.
  exit code: 1
Joshua Nelson (Dec 29 2020 at 17:32, on Zulip):

bjorn3 said:

There are cases where it is not optional like linux + musl, fuchsia and fortanix.

ok, so don't support those out of tree :shrug: anyone doing complicated bootstrapping things will have to use x.py anyway

Joshua Nelson (Dec 29 2020 at 17:32, on Zulip):

this is for the very simplest "I want to add an API to the standard library"

Joshua Nelson (Dec 29 2020 at 17:34, on Zulip):

and in fact it would break on things like https://github.com/rust-lang/rust/pull/68692#issuecomment-580899667 (it would compile fine out of tree), but I'm ok with that because it's very rare and would be caught during the subtree sync

Pietro Albini (Dec 29 2020 at 17:38, on Zulip):

Joshua Nelson said:

Pietro Albini said:

(mostly on CI -- which doesn't use git submodule -- and when you need to interact with the commit history)

how does CI build the compiler without using x.py? x.py runs git submodule

https://github.com/rust-lang/rust/blob/master/src/ci/init_repo.sh

Pietro Albini (Dec 29 2020 at 17:39, on Zulip):

executed before ./x.py

Pietro Albini (Dec 29 2020 at 17:39, on Zulip):

basically for the big submodules we do some trickery to remove the submodule itself and replace it with the archive of the last commit

Pietro Albini (Dec 29 2020 at 17:39, on Zulip):

which speeds up things a lot, especially for llvm

Joshua Nelson (Dec 29 2020 at 17:40, on Zulip):

oh boy :laughing:

Joshua Nelson (Dec 29 2020 at 17:40, on Zulip):

it looks like you only do that for llvm and some of the docs though: https://github.com/rust-lang/rust/blob/158f8d034b15e65ba8dc0d066358dd0632bfcd6e/src/ci/init_repo.sh#L50

Joshua Nelson (Dec 29 2020 at 17:40, on Zulip):

so it wouldn't be affected by making backtrace and stdarch a subtree

Pietro Albini (Dec 29 2020 at 17:41, on Zulip):

I'm curious how fast it would be if we ran that unconditionally for every submodule

Eric Huss (Dec 29 2020 at 17:46, on Zulip):

The concern is that if we want to make the dependency between rustc and the standard library explicit, it wouldn't work. For example:

# Somewhere in a rustc Cargo.toml.
std = { path="../../library/std" }

These can't cross workspace boundaries. It could maybe work if Cargo supported nested workspaces. Just pointing out that making it a separate workspace will make things more difficult.

I understand that splitting into a separate repository has its benefits, but there are quite a few drawbacks as well:

At least for using a separate workspace, I think it is feasible, but there are drawbacks which will make it harder to work with. The difference between cd library && cargo check and cargo check -p test seems minimal and trivial, and I don't think the benefit of being able to cd library && cargo check over cargo check -p test to be worth it.

I'm not sure Zulip is really a great way to discuss all the issues.

Joshua Nelson (Dec 29 2020 at 17:47, on Zulip):

I'm not sure Zulip is really a great way to discuss all the issues.

would hackmd be better maybe?

Joshua Nelson (Dec 29 2020 at 17:48, on Zulip):

I don't think the benefit of being able to cd library && cargo check over cargo check -p test to be worth it.

I agree if we can get cargo check to give a reasonable error

Joshua Nelson (Dec 29 2020 at 17:48, on Zulip):

right now it gives about 150 errors that Sized isn't implemented for (), which is basically useless for figuring out what went wrong

Joshua Nelson (Dec 29 2020 at 17:49, on Zulip):

I also want to point out one of the motivations is not just 'fewer commands' but also 'make the standard library less special'

bjorn3 (Dec 29 2020 at 17:49, on Zulip):

IMO splitting the workspace is a good idea, but splitting the repo is not really.

Joshua Nelson (Dec 29 2020 at 17:50, on Zulip):

bjorn3 said:

IMO splitting the workspace is a good idea, but splitting the repo is not.

after reading about CI and the issue tracker, I agree actually

Joshua Nelson (Dec 29 2020 at 17:50, on Zulip):

I'll take that out of the MCP

Joshua Nelson (Dec 29 2020 at 17:50, on Zulip):

I suspect once you have a separate repository, people will want to have some way do something other than cargo test, which I'm uncertain is possible.

@Eric Huss what do you mean by 'other than cargo test'?

Joshua Nelson (Dec 29 2020 at 17:51, on Zulip):

another alternative to this is to make an x.py wrapper that knows that x build in library/std means x.py build --stage 0 library/std but that gets even further from the goal of 'make the standard library less special'

Laurențiu Nicola (Dec 29 2020 at 17:52, on Zulip):

There seems to be a high risk that issue tracking would be a mess. How would this work?

By disabling the issue tracker, maybe.

bjorn3 (Dec 29 2020 at 17:52, on Zulip):

You could have ./x.py accept paths relative to the current working dir and have it default to ..

Joshua Nelson (Dec 29 2020 at 17:53, on Zulip):

sure, and these would all be good QOL things, but they're mostly good for existing contributors

Joshua Nelson (Dec 29 2020 at 17:53, on Zulip):

I want to help people who've never used x.py before and don't know why they need it

Eric Huss (Dec 29 2020 at 17:55, on Zulip):

Joshua Nelson said:

I'm not sure Zulip is really a great way to discuss all the issues.

would hackmd be better maybe?

I'm not sure. I don't really want to put much energy into this. Just trying to point out that if you move forward, it will make things more difficult.

Joshua Nelson said:

I don't think the benefit of being able to cd library && cargo check over cargo check -p test to be worth it.

I agree if we can get cargo check to give a reasonable error

I don't agree. I wouldn't expect to be able to check out any large project and run random commands (like make) and just expect it to work.

Joshua Nelson said:

I suspect once you have a separate repository, people will want to have some way do something other than cargo test, which I'm uncertain is possible.

Eric Huss what do you mean by 'other than cargo test'?

Like being able to build something with that customized standard library.

bjorn3 (Dec 29 2020 at 17:56, on Zulip):

I don't agree. I wouldn't expect to be able to check out any large project and run random commands (like make) and just expect it to work.

For pretty much all rust projects, even large ones cargo build just works. (Assuming you have the necessary C libraries installed)

Joshua Nelson (Dec 29 2020 at 18:07, on Zulip):

as a point of interest, servo also has ./mach build --dev

Joshua Nelson (Dec 29 2020 at 18:08, on Zulip):

but the error for cargo check, while not exactly helpful, at least gives you some idea what went wrong:

error[E0463]: can't find crate for `rustc_ast`
  --> components/script_plugins/lib.rs:22:1
   |
22 | extern crate rustc_ast;
   | ^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
Joshua Nelson (Dec 29 2020 at 18:09, on Zulip):

compare that to cargo check in library/std: https://termbin.com/txtu

Joshua Nelson (Dec 29 2020 at 18:11, on Zulip):
# The beginning of this script is both valid shell and valid python,
# such that the script starts with the shell and is reexecuted with
# the right python.
''':' && if [ ! -z "$MSYSTEM" ] ; then exec python "$0" "$@" ; else which python2.7 > /dev/null 2> /dev/null && exec python2.7 "$0" "$@" || exec python "$0" "$@" ; fi
'''

heh, maybe we should do this for x.py

bjorn3 (Dec 29 2020 at 18:15, on Zulip):

That reminds me of https://github.com/bjorn3/rustc_codegen_cranelift/blob/dbee13661efa269cb4cd57bb4c6b99a19732b484/scripts/filter_profile.rs which is a bash script that jit compiles itself as rust executable using cg_clif.

Joshua Nelson (Dec 29 2020 at 18:17, on Zulip):

I don't agree. I wouldn't expect to be able to check out any large project and run random commands (like make) and just expect it to work.

for what it's worth, this comes up over and over again:

Joshua Nelson (Dec 29 2020 at 18:17, on Zulip):

it's not just me :/

nagisa (Dec 29 2020 at 18:34, on Zulip):

Sounds like it'd be harder to dogfood compiler features to me.

Joshua Nelson (Dec 29 2020 at 18:34, on Zulip):

nagisa said:

Sounds like it'd be harder to dogfood compiler features to me.

why do you think so?

nagisa (Dec 29 2020 at 18:36, on Zulip):

well, if the expectation is that checking out a std/ repo (if we're splitting it out) and just cargo +nightly build works, then you need to have a nightly published with features you want to use

nagisa (Dec 29 2020 at 18:36, on Zulip):

which by definition precludes dogfooding in libstd at the same time a feature is implemented in the compiler.

Joshua Nelson (Dec 29 2020 at 18:36, on Zulip):

oh I see - we could use beta out of tree instead

Joshua Nelson (Dec 29 2020 at 18:36, on Zulip):

and that actually works better because then we can add rust-toolchain and automatically have the right version

Joshua Nelson (Dec 29 2020 at 18:37, on Zulip):

I'd just have to figure out a way to pass --cfg bootstrap

nagisa (Dec 29 2020 at 18:38, on Zulip):

if we don't split out std into a separate repo/worktree or whatever, then it doesn't really matter either way

nagisa (Dec 29 2020 at 18:40, on Zulip):

because then you can have a readme that reads something along the lines of "well, you can try cargo build and if it doesn't work go run x.py from repo root..."

nagisa (Dec 29 2020 at 18:40, on Zulip):

and in most cases the former would work.

nagisa (Dec 29 2020 at 18:40, on Zulip):

Joshua Nelson said:

oh I see - we could use beta out of tree instead

I don't see how that solves anything?

bjorn3 (Dec 29 2020 at 18:41, on Zulip):

Libstd has to compile with beta anyway for bootstrapping purposes.

Laurențiu Nicola (Dec 29 2020 at 18:41, on Zulip):

Are there PRs that introduce new language/compiler features and also add them to libstd at the same time?

Joshua Nelson (Dec 29 2020 at 18:41, on Zulip):

Laurențiu Nicola said:

Are there PRs that introduce new language/compiler features and also add them to libstd at the same time?

yes, let me find a link

Laurențiu Nicola (Dec 29 2020 at 18:41, on Zulip):

IMHO, needing a published compiler is more of a feature than a bug

nagisa (Dec 29 2020 at 18:41, on Zulip):

Libstd has to compile with beta anyway for bootstrapping purposes.

Sure, but its "just" a question of cfg(stage0). Are you proposing that contributors would be changing stage0 code?

Joshua Nelson (Dec 29 2020 at 18:42, on Zulip):

nagisa said:

Sure, but its "just" a question of cfg(stage0). Are you proposing that contributors would be changing stage0 code?

yes, I think that makes more sense then having them change stage1

nagisa (Dec 29 2020 at 18:43, on Zulip):

who would ensure that cfg(stage0) and cfg(not(stage0)) stay in sync? Until now typically you'd just delete the cfg(stage0) code when trains roll over.

bjorn3 (Dec 29 2020 at 18:44, on Zulip):

Why would that need to change?

nagisa (Dec 29 2020 at 18:44, on Zulip):

If contributors adjust code in cfg(stage0) then we position ourselves for a situation where changes just disappear.

Joshua Nelson (Dec 29 2020 at 18:44, on Zulip):

nagisa said:

who would ensure that cfg(stage0) and cfg(not(stage0)) stay in sync? Until now typically you'd just delete the cfg(stage0) code when trains roll over.

you could still do that with subtree syncs, the nice thing about subtree is you can change it on either end

Joshua Nelson (Dec 29 2020 at 18:44, on Zulip):

it would make the syncs a little more prone to conflict but not by a ton I don't think

bjorn3 (Dec 29 2020 at 18:45, on Zulip):

nagisa said:

If contributors adjust code in cfg(stage0) then we position ourselves for a situation where changes just disappear.

A non-compiler contributor rarely has to touch cfg(not(bootstrap)) code. That is only for when the compiler changed.

nagisa (Dec 29 2020 at 18:46, on Zulip):

what is a non-compiler contributor? Are we looking to reorganize the ownership of the libstd implementation again?

nagisa (Dec 29 2020 at 18:47, on Zulip):

Given that implementation of libstd is currently under T-compiler purview AFAIK

bjorn3 (Dec 29 2020 at 18:47, on Zulip):

I mean someone that only want to change libstd and not the compiler. For example to improve the performance of say Vec or add a new api.

Joshua Nelson (Dec 29 2020 at 18:47, on Zulip):

'someone who primarily contributes to the standard library'

Are we looking to reorganize the ownership of the libstd implementation again?

no, none of this is oriented towards repeat contributors, this is for people who want to make a small API change and now have to think about bootstrapping

Joshua Nelson (Dec 29 2020 at 18:53, on Zulip):

Joshua Nelson said:

Laurențiu Nicola said:

Are there PRs that introduce new language/compiler features and also add them to libstd at the same time?

yes, let me find a link

couldn't find it :( but it was related to adding a new lang intrinsic

Joshua Nelson (Dec 29 2020 at 18:53, on Zulip):

also I want to be clear: I am not proposing to change the bootstrapping model at all. I just want an easier way to say x.py build --stage 0 library/std

Joshua Nelson (Dec 29 2020 at 18:54, on Zulip):

@Laurențiu Nicola see https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html#stages-and-std for why 'use a fixed version of the compiler' doesn't work

Laurențiu Nicola (Dec 29 2020 at 18:57, on Zulip):

Which part? I wasn't proposing that new compilers would be able to link an old libstd to produce working executables

Joshua Nelson (Dec 29 2020 at 18:57, on Zulip):

Laurențiu Nicola said:

IMHO, needing a published compiler is more of a feature than a bug

^ this part

Laurențiu Nicola (Dec 29 2020 at 18:59, on Zulip):

Joshua Nelson said:

couldn't find it :( but it was related to adding a new lang intrinsic

Yeah, that makes sense

nagisa (Dec 29 2020 at 19:02, on Zulip):

As far as subtrees are concerned, I have a hard time imagining myself going through multiple repos to review changes to libstd. Use of subtree has different tradeoffs here than clippy/miri/etc tools if nothing else about libstd changes. clippy/miri generally develop features in the separate repo and whatever compatibility bits necessary with the compiler in rust-lang/rust.

The only way libstd split into another repo makes sense is if we look towards adopting a similar model to clippy/miri. Which also implies reduced dogfooding, which might actually be fine.

Yet another consideration if we do so is how that impacts tooling around compiler that we have. For instance we do @rust-timer perf a number of libstd changes which then benches the bootstrapped compiler with the changed libstd -- having a separate repo for libstd makes that harder if not impossible to do automatically?

Joshua Nelson (Dec 29 2020 at 19:03, on Zulip):

personally I think we should drop the subtree part of this

Joshua Nelson (Dec 29 2020 at 19:04, on Zulip):

like you and Eric Huss brought up, that has a lot more complications that are incidental to the actual change I want, which is for cargo build to work

nagisa (Dec 29 2020 at 19:05, on Zulip):

Yeah, if the change is just about getting cd library/libstd && cargo build work out of the box (maybe most of the time if not always) then its a no-brainer.

nagisa (Dec 29 2020 at 19:08, on Zulip):

@Joshua Nelson I see you striked out the subtree, you want to do same for "Make a new rust-lang/library repository" under "Implementation" section.

Joshua Nelson (Dec 29 2020 at 19:18, on Zulip):

thanks, done

Josh Triplett (Dec 30 2020 at 07:09, on Zulip):

@Joshua Nelson FWIW, I really really hope that the library and similar don't start using subtree. That would make it much harder for me to contribute to them.

Josh Triplett (Dec 30 2020 at 07:09, on Zulip):

I do like the idea of being able to build in a subdirectory.

Josh Triplett (Dec 30 2020 at 07:10, on Zulip):

But keeping rust-lang/rust more self-contained makes contribution much simpler, to me.

Josh Triplett (Dec 30 2020 at 07:10, on Zulip):

And easier to coordinate changes.

Josh Triplett (Dec 30 2020 at 07:10, on Zulip):

(Caught up now, glad to hear the subtree was dropped, sorry for the distraction.)

triagebot (Dec 30 2020 at 23:23, on Zulip):

@T-compiler: Proposal #394 has been seconded, and will be approved in 10 days if no objections are raised.

RalfJ (Jan 03 2021 at 11:45, on Zulip):

FWIW, if the main concern is "people do cargo check and the resulting error is awful", one could also imagine having a file like .no-cargo or so, which makes cargo bail immediately with a custom error message -- and that error could tell people the right x.py invocations instead.

Joshua Nelson (Jan 03 2021 at 15:20, on Zulip):

RalfJ said:

FWIW, if the main concern is "people do cargo check and the resulting error is awful", one could also imagine having a file like .no-cargo or so, which makes cargo bail immediately with a custom error message -- and that error could tell people the right x.py invocations instead.

I already tried this, it breaks things like cargo tree: https://github.com/rust-lang/rust/pull/79021

RalfJ (Jan 03 2021 at 16:22, on Zulip):

Well, that's using a hack to do this

RalfJ (Jan 03 2021 at 16:22, on Zulip):

if we add support for this in cargo we could do better

Joshua Nelson (Jan 03 2021 at 16:36, on Zulip):

I would rather fix this properly than add hacks to cargo :/

Joshua Nelson (Jan 03 2021 at 16:36, on Zulip):

I can't imagine anyone using this besides rust-lang/rust

Nadrieril (Jan 03 2021 at 20:02, on Zulip):

Any other project that can't use cargo for some reason? Like maybe projects that need xargo

oliver (Jan 03 2021 at 20:28, on Zulip):

rust-analyzer and Redox?

bjorn3 (Jan 03 2021 at 20:34, on Zulip):

rust-analyzer uses xtask for a variety of things, but can be compiled just fine without. You then just have to build the vscode extension manually.

triagebot (Jan 14 2021 at 13:30, on Zulip):

This proposal has been accepted: #394.

Last update: May 07 2021 at 06:45UTC