2016-09-02 03:55:29 -05:00
|
|
|
[workspace]
|
|
|
|
|
members = [
|
2018-08-21 21:50:46 -05:00
|
|
|
"src/bootstrap",
|
|
|
|
|
"src/rustc",
|
|
|
|
|
"src/libstd",
|
|
|
|
|
"src/libtest",
|
|
|
|
|
"src/librustc_codegen_llvm",
|
|
|
|
|
"src/tools/cargotest",
|
|
|
|
|
"src/tools/clippy",
|
|
|
|
|
"src/tools/compiletest",
|
|
|
|
|
"src/tools/error_index_generator",
|
|
|
|
|
"src/tools/linkchecker",
|
|
|
|
|
"src/tools/rustbook",
|
|
|
|
|
"src/tools/unstable-book-gen",
|
|
|
|
|
"src/tools/tidy",
|
|
|
|
|
"src/tools/build-manifest",
|
|
|
|
|
"src/tools/remote-test-client",
|
|
|
|
|
"src/tools/remote-test-server",
|
|
|
|
|
"src/tools/rust-installer",
|
|
|
|
|
"src/tools/cargo",
|
|
|
|
|
"src/tools/rustdoc",
|
|
|
|
|
"src/tools/rls",
|
|
|
|
|
"src/tools/rustfmt",
|
|
|
|
|
"src/tools/miri",
|
|
|
|
|
"src/tools/rustdoc-themes",
|
2020-01-13 15:40:19 -06:00
|
|
|
"src/tools/unicode-table-generator",
|
2018-07-26 16:58:55 -05:00
|
|
|
]
|
|
|
|
|
exclude = [
|
2018-11-25 06:59:52 -06:00
|
|
|
"build",
|
2018-11-25 15:15:20 -06:00
|
|
|
# HACK(eddyb) This hardcodes the fact that our CI uses `/checkout/obj`.
|
|
|
|
|
"obj",
|
2017-04-20 16:32:54 -05:00
|
|
|
]
|
|
|
|
|
|
2018-07-14 10:04:33 -05:00
|
|
|
# Curiously, LLVM 7.0 will segfault if compiled with opt-level=3
|
|
|
|
|
# See issue https://github.com/rust-lang/rust/issues/52378
|
|
|
|
|
[profile.release]
|
|
|
|
|
opt-level = 2
|
|
|
|
|
[profile.bench]
|
|
|
|
|
opt-level = 2
|
|
|
|
|
|
2016-11-16 11:19:02 -06:00
|
|
|
# These options are controlled from our rustc wrapper script, so turn them off
|
|
|
|
|
# here and have them controlled elsewhere.
|
|
|
|
|
[profile.dev]
|
|
|
|
|
debug = false
|
|
|
|
|
debug-assertions = false
|
|
|
|
|
[profile.test]
|
|
|
|
|
debug = false
|
|
|
|
|
debug-assertions = false
|
2017-04-29 18:11:58 -05:00
|
|
|
|
2018-01-08 15:56:22 -06:00
|
|
|
# We want the RLS to use the version of Cargo that we've got vendored in this
|
|
|
|
|
# repository to ensure that the same exact version of Cargo is used by both the
|
|
|
|
|
# RLS and the Cargo binary itself. The RLS depends on Cargo as a git repository
|
|
|
|
|
# so we use a `[patch]` here to override the github repository with our local
|
|
|
|
|
# vendored copy.
|
2017-09-11 19:17:31 -05:00
|
|
|
[patch."https://github.com/rust-lang/cargo"]
|
2018-08-21 21:50:46 -05:00
|
|
|
cargo = { path = "src/tools/cargo" }
|
2017-09-01 00:13:15 -05:00
|
|
|
|
2018-07-31 16:16:55 -05:00
|
|
|
[patch.crates-io]
|
2018-01-08 15:56:22 -06:00
|
|
|
# Similar to Cargo above we want the RLS to use a vendored version of `rustfmt`
|
|
|
|
|
# that we're shipping as well (to ensure that the rustfmt in RLS and the
|
2018-07-09 03:04:28 -05:00
|
|
|
# `rustfmt` executable are the same exact version).
|
2018-08-21 21:50:46 -05:00
|
|
|
rustfmt-nightly = { path = "src/tools/rustfmt" }
|
2018-07-09 03:04:28 -05:00
|
|
|
|
2018-08-21 21:50:46 -05:00
|
|
|
# See comments in `src/tools/rustc-workspace-hack/README.md` for what's going on
|
2018-07-31 16:16:55 -05:00
|
|
|
# here
|
2018-08-21 21:50:46 -05:00
|
|
|
rustc-workspace-hack = { path = 'src/tools/rustc-workspace-hack' }
|
2018-07-31 16:16:55 -05:00
|
|
|
|
std: Depend directly on crates.io crates
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
2018-11-19 23:52:50 -06:00
|
|
|
# See comments in `tools/rustc-std-workspace-core/README.md` for what's going on
|
|
|
|
|
# here
|
|
|
|
|
rustc-std-workspace-core = { path = 'src/tools/rustc-std-workspace-core' }
|
2019-02-07 05:08:05 -06:00
|
|
|
rustc-std-workspace-alloc = { path = 'src/tools/rustc-std-workspace-alloc' }
|
bootstrap: Merge the libtest build step with libstd
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
2019-08-16 10:29:08 -05:00
|
|
|
rustc-std-workspace-std = { path = 'src/tools/rustc-std-workspace-std' }
|
std: Depend directly on crates.io crates
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
2018-11-19 23:52:50 -06:00
|
|
|
|
2018-12-01 04:36:32 -06:00
|
|
|
[patch."https://github.com/rust-lang/rust-clippy"]
|
2018-08-21 21:50:46 -05:00
|
|
|
clippy_lints = { path = "src/tools/clippy/clippy_lints" }
|
