| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.
|
|
Uses relative libdir to place libraries on all stages.
Adds verbose installation output.
|
|
|
|
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
|
|
Include llvm-ar with llvm-tools component
Adds the `llvm-ar` tool to the `llvm-tools` component. This is useful for [building and linking native code](https://doc.rust-lang.org/cargo/reference/build-scripts.html#case-study-building-some-native-code) in cargo build scripts without needing to use the platform specific `ar`. According to #58663 it is also useful for WASM.
`llvm-ar` is very small (~82KB), so it does not significantly increase the size of the `llvm-tools` component.
Fixes #58663
|
|
|
|
Output copy actions
|
|
I used version-channel-sha, hopefully that should work.
I checked that bootstrap builds, but I cannot check anything else since the llvm
build process is started from cargo, and thus calls clang, and thus I hit the
same bug I hope to fix with this change.
Hopefully fixes #59034.
|
|
|
|
|
|
|
|
|
|
NVPTX target specification
This change adds a built-in `nvptx64-nvidia-cuda` GPGPU no-std target specification and a basic PTX assembly smoke tests.
The approach is taken here and the target spec is based on `ptx-linker`, a project started about 1.5 years ago. Key feature: bitcode object files being linked with LTO into the final module on the linker's side.
Prior to this change, the linker used a `ld` linker-flavor, but I think, having the special CLI convention is a more reliable way.
Questions about further progress on reliable CUDA workflow with Rust:
1. Is it possible to create a test suite `codegen-asm` to verify end-to-end integration with LLVM backend?
1. How would it be better to organise no-std `compile-fail` tests: add `#![no_std]` where possible and mark others as `ignore-nvptx` directive, or alternatively, introduce `compile-fail-no-std` test suite?
1. Can we have the `ptx-linker` eventually be integrated as `rls` or `clippy`? Hopefully, this should allow to statically link against LLVM used in Rust and get rid of the [current hacky solution](https://github.com/denzp/rustc-llvm-proxy).
1. Am I missing some methods from `rustc_codegen_ssa::back::linker::Linker` that can be useful for bitcode-only linking?
Currently, there are no major public CUDA projects written in Rust I'm aware of, but I'm expecting to have a built-in target will create a solid foundation for further experiments and awesome crates.
Related to #38789
Fixes #38787
Fixes #38786
|
|
Bump bootstrap compiler to 1.33 beta
r? @alexcrichton or @pietroalbini
cc @rust-lang/release
|
|
|
|
|
|
This also makes compiletest no longer always retest everything.
|
|
|
|
|
|
|
|
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.
|
|
bootstrap: clean up a few clippy findings
remove useless format!()s
remove redundant field names in a few struct initializations
pass slice instead of a vector to a function
use is_empty() instead of comparisons to .len()
No functional change intended.
|
|
Use lld directly for Fuchsia target
Fuchsia already uses lld as the default linker, so there's no reason
to always invoke it through Clang, instead we can simply invoke lld
directly and pass the set of flags that matches Clang.
|
|
Fuchsia already uses lld as the default linker, so there's no reason
to always invoke it through Clang, instead we can simply invoke lld
directly and pass the set of flags that matches Clang.
|
|
This commit adds opt-in support to the compiler to link to `jemalloc` in
the compiler. When activated the compiler will depend on `jemalloc-sys`,
instruct jemalloc to unprefix its symbols, and then link to it. The
feature is activated by default on Linux/OSX compilers for x86_64/i686
platforms, and it's not enabled anywhere else for now. We may be able to
opt-in other platforms in the future! Also note that the opt-in only
happens on CI, it's otherwise unconditionally turned off by default.
Closes #36963
|
|
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.
|
|
|
|
bootstrap: clean up a few clippy findings
remove useless format!()s
remove redundant field names in a few struct initializations
pass slice instead of a vector to a function
use is_empty() instead of comparisons to .len()
No functional change intended.
|
|
remove useless format!()s
remove redundant field names in a few struct initializations
pass slice instead of a vector to a function
use is_empty() instead of comparisons to .len()
No functional change intended.
|
|
Fallback to the release number as we can't get the
git commit sha as we're not in a git repository.
Fixes #55341
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
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.
|
|
print its name in the error message.
|
|
If the rust-enabled lldb was built, then use it when running the
debuginfo tests. Updating the lldb submodule was necessary as this
needed a way to differentiate the rust-enabled lldb, so I added a line
to the --version output.
This adds compiletest commands to differentiate between the
rust-enabled and non-rust-enabled lldb, as is already done for gdb. A
new "rust-lldb" header directive is also added, but not used in this
patch; I plan to use it in #54004.
This updates all the tests.
|
|
This patch adds a few improvements to how the build system finds
LLVM's FileCheck program.
* On Fedora, the system LLVM installs FileCheck in the "llvm"
subdirectory of the LLVM libdir. This patch teaches the build
system to look there.
* This adds a configure option to specify which llvm-config executable
to use. This is handy on systems that can parallel install multiple
versions of LLVM; for example I can now:
./configure --llvm-config=/bin/llvm-config-5.0-64
... to build against LLVM 5, rather than whatever the default
llvm-config might be.
* Finally, this adds a configure- and config.toml- option to set the
path to FileCheck. This is handy when building against an LLVM
where FileCheck was not installed. This happens on compatibility
installs of LLVM on Fedora.
|
|
Clean up dependency tracking in Rustbuild [2/2]
Make `clear_if_dirty` calls in `Builder::cargo` with stamp dependencies for the given Mode.
Continuation of #50904
Ref issue #50509
r? @Mark-Simulacrum
|
|
|
|
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
|
|
add llvm-readobj to llvm-tools-preview
Similar to readelf but supports more object formats (it seems). Particularly useful to inspect in detail sections (e.g. their flags) and symbols (e.g. their types).
r? @alexcrichton
cc @dvc94ch
|
|
|
|
|
|
|
|
|
|
This optionally adds lldb (and clang, which it needs) to the build.
Because rust uses LLVM 7, and because clang 7 is not yet released, a
recent git master version of clang is used.
The lldb that is used includes the Rust plugin.
lldb is only built when asked for, or when doing a nightly build on
macOS. Only macOS is done for now due to difficulties with the Python
dependency.
|
|
This allows clearing it out and building it separately from the
compiler. Since it's essentially a different and separate crate this
makes sense to do, each cargo invocation should generally happen in its
own directory.
|
|
Provide llvm-strip in llvm-tools component
Shipping this tool gives people reliable way to reduce the generated executable size.
I'm not sure if this strip tool is available from the llvm version current rust is built on. But let's take a look. @japaric
|
