| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This reverts commit 3eb4890dfe6db0279fdd3cda19f9643873ae3db9, reversing
changes made to 7a4df3b53da369110984a2b57419c05a53e33b38.
|
|
|
|
Uses relative libdir to place libraries on all stages.
Adds verbose installation output.
|
|
Rework how bootstrap tools are built
This makes bootstrap tools buildable and testable in stage 0 with the downloaded bootstrap compiler, futhermore, it makes it such that they cannot be built in any other stage.
Notably, this will also mean that compiletest may need to wait a cycle before it can use changes to `libtest`, as it no longer depends on the in-tree libtest.
|
|
|
|
r=Mark-Simulacrum
Add librustc and libsyntax to rust-src distribution.
Fixes #58268.
|
|
|
|
This allows us to e.g. test compiletest, including doctests, in stage 0
without building a fresh compiler and rustdoc.
|
|
|
|
|
|
use `SOURCE_DATE_EPOCH` for man page time if set
Fixes #57776.
|
|
|
|
|
|
The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
|
|
|
|
See https://github.com/rust-lang/rust/pull/53774#issuecomment-419704939
|
|
This fixes a mistake where miri was accidentally left out of the
build-manifest parsing, meaning that today's nightly generated a
manifest with invalid urls!
|
|
|
|
|
|
It's only meant for rustc, so we should only install it once!
|
|
When building a distributed compiler on Linux where we use ThinLTO to
create the LLVM shared object this commit switches the compiler to
dynamically linking that LLVM artifact instead of statically linking to
LLVM. The primary goal here is to reduce CI compile times, avoiding two+
ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll
reuse the one ThinLTO step done by LLVM's build itself.
Lots of discussion about this change can be found [here] and down. A
perf run will show whether this is worth it or not!
[here]: https://github.com/rust-lang/rust/pull/53245#issuecomment-417015334
|
|
|
|
This reverts commit f1051b574c26e20608ff26415a3dddd13f140925, reversing
changes made to 833e0b3b8a9f1487a61152ca76f7f74a6b32cc0c.
|
|
This commit switches the standard library to using the `backtrace-sys`
crate from crates.io instead of duplicating the logic here in the Rust
repositor with the `backtrace-sys`'s crate's logic.
Eventually this will hopefully be a good step towards using the
`backtrace` crate directly from crates.io itself, but we're not quite
there yet! Hopefully this is a small incremental first step we can take.
|
|
When building a distributed compiler on Linux where we use ThinLTO to
create the LLVM shared object this commit switches the compiler to
dynamically linking that LLVM artifact instead of statically linking to
LLVM. The primary goal here is to reduce CI compile times, avoiding two+
ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll
reuse the one ThinLTO step done by LLVM's build itself.
Lots of discussion about this change can be found [here] and down. A
perf run will show whether this is worth it or not!
[here]: https://github.com/rust-lang/rust/pull/53245#issuecomment-417015334
|
|
bootstrap: fix edition
A byproduct of work on https://github.com/rust-lang/rust/pull/56595; done with `cargo fix --edition`.
|
|
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
|
|
|
|
Various minor/cosmetic improvements to code
r? @Centril 😄
|
|
|
|
This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.
I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
|
|
The files src/libstd/sys/sgx/*.rs are mostly copied/adapted from
the wasm target.
This also updates the dlmalloc submodule to the very latest version.
|
|
|
|
This commit deletes the `alloc_system` crate from the standard
distribution. This unstable crate is no longer needed in the modern
stable global allocator world, but rather its functionality is folded
directly into the standard library. The standard library was already the
only stable location to access this crate, and as a result this should
not affect any stable code.
|
|
Remove the `alloc_jemalloc` crate
This commit removes the `alloc_jemalloc` crate from the standard library and all related configuration. We will no longer be shipping this unstable crate. Rationale for this is provided on https://github.com/rust-lang/rust/issues/36963 and the many linked issues, but I can inline rationale here if desired!
We currently rely on jemalloc for increased perf in the Rust compiler, however. [This perf run shows](https://perf.rust-lang.org/compare.html?start=74ff7dcb1388e60a613cd6050bcd372a3cc4998b&end=7e7928dc0340d79b404e93f0c79eb4b946c1d669&stat=wall-time) that if we switch to glibc 2.23's allocator that it's slower than jemalloc across many benchmarks. [This perf run, however](https://perf.rust-lang.org/compare.html?start=22cc2ae8057d14e980b7c784e1eb2eee26b59e7d&end=10c95ccfa7a7adc12f4e608621ca29f9b98eed29), shows that if we use `jemalloc-sys` from crates.io then rustc actually gets faster across all benchmarks! (presumably because it has a more recent version of jemalloc than our submodule).
As a result, it's expected that this doesn't regress any code (as it's just removing an unstable crate) and it should actually improve rustc performance because it updates jemalloc.
Closes #36963
|
|
Bump cargo-vendor version
Currently we pin `cargo-vendor` to 0.1.4, which doesn't set the `User-Agent` HTTP header. crates.io is going to require that header in the near future, so this PR bumps the pinned version of the crate to the latest one (which correctly sets the header).
r? @Mark-Simulacrum
cc @sgrif
|
|
This commit removes all jemalloc related submodules, configuration, etc,
from the bootstrap, from the standard library, and from the compiler.
This will be followed up with a change to use jemalloc specifically as
part of rustc on blessed platforms.
|
|
r=Mark-Simulacrum
Add libproc_macro to rust-src distribution
Fixes #55279
|
|
|
|
|
|
|
|
In addition to to updating Cargo's submodule and Cargo's dependencies,
this also updates Cargo's build to build OpenSSL statically into Cargo
as well as libcurl unconditionally. This removes OpenSSL build logic
from the bootstrap code, and otherwise requests that even on OSX we
build curl statically.
|
|
|
|
|
|
We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup. See the discussion in
https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for
background on this decision. There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed.
This patch changes dist.rs to put lldb into rustlib, following what
was done for the other LLVM tools in #53955, and then fixes rust-lldb
to prefer that lldb, if it exists.
See issue #48168
|
|
Previously we just weren't shipping this at all as we were only looking for the
Linux version!
|
|
This commit tweaks the layout of a few components that we distribute to
hopefully fix across all platforms the recent issues with LLD being unable to
find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic
library, which means that LLVM tools by default link to LLVM dynamically rather
than statically. This in turn means that the tools, at runtime, need to find the
LLVM shared library.
LLVM's shared library is currently distributed as part of the rustc component.
This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are
in two locations:
* LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld`
* Other LLVM tools are shipped at `$sysroot/bin`
Each LLVM tool has an embedded rpath directive indicating where it will search
for dynamic libraries. This currently points to `../lib` and is presumably
inserted by LLVM's build system. Unfortunately, though, this directive is only
correct for the LLVM tools at `$sysroot/bin`, not LLD!
This commit is targeted at fixing this situation by making two changes:
* LLVM tools other than LLD are moved in the distribution to
`$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should
position them for...
* The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib`
Together this means that all tools should natively be able to find the shared
object and the shared object should be installed all the time for the various
tools. Overall this should...
Closes #53813
|
|
A recent change (#53245) started to build LLVM with ThinLTO enabled and to
ensure that compile times are kept down it builds LLVM dynamically by default to
ensure that all the various LLVM tools aren't redoing all that optimization
work. This means, however, that all LLVM tools depend on LLVM's dynamic library
by default.
While the LLVM tools and LLDB components were updated to include the shared
library we accidentally forgot about LLD, included with the main rustc
component. LLD also links dynamically to LLVM and ships a non-working binary
right now because of this!
This commit updates our distribution to ship the LLVM dynamic library with the
compiler libraries. While not technically needed for rustc itself to operate
(right now) it may be needed for LLD, and otherwise it serves as a good basis
for the other LLVM tools components to work with as well.
This should...
Closes #53813
|
|
|
