This commit updates the metadata location logic to ignore errors when
calling `fs::canonicalize`. Canonicalization was added historically so
multiple `-L` paths to the same directory don't print errors about
multiple candidates (since rustc can deduplicate same-named paths), but
canonicalization doesn't work on all filesystems. Cargo, for example,
always uses this sort of fallback where it will opportunitistically try
to canonicalize but fall back to using the input path if it otherwise
doesn't work.
If rustc is run on a filesystem that doesn't support canonicalization
then the effect of this change will be that `-L` paths which logically
point to the same directory will cause errors, but that's a rare enough
occurrence it shouldn't cause much issue in practice. Otherwise rustc
doesn't work at all today on those sorts of filesystem where
canonicalization isn't supported!
This fixes various cases where LD could not guess dllexport correctly and greatly improves compatibility with LLD which is not going to support linker scripts anytime soon
Fix opening docs for std crates with ./x.py doc --open library/*
The directories for core, alloc, std, proc_macro, and test crates now
correspond directly to the crate name, and stripping the "lib" prefix is
no longer necessary.
The directories for core, alloc, std, proc_macro, and test crates now
correspond directly to the crate name and stripping the "lib" prefix is
no longer necessary.
Cache non-exhaustive separately from attributes
This prevents cross-crate attribute loading from metadata just for non_exhaustive checking; cross-crate attribute loading implies disk reading and is relatively slow.
Fix RefUnwindSafe & UnwinsSafe impls for lazy::SyncLazy
I *think* we should implement those unconditionally with respect to `F`.
The user code can't observe the closure in any way, and we poison lazy if the closure itself panics.
But I've never fully wrapped my head around `UnwindSafe` traits, so 🤷♂️
Add str::[r]split_once
This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer:
* https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282
* https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim
In theory, once const-generics are done, this functionality could be achieved without a dedicated method with
```rust
match s.splitn(delimier, 2).collect_array::<2>() {
Some([prefix, suffix]) => todo!(),
None => todo!(),
}
```
Even in that world, having a dedicated method seems clearer on the intention.
I am not sure about naming -- this is something I've just came up with yesterday, I don't know off the top of my head analogs in other languages.
If T-libs thinks this is a reasonable API to have, I'll open a tracking issue and add more thorough tests.
Add #[inline] to RawWaker::new
`RawWaker::new` is used when creating a new waker or cloning an existing one,
for example as in code below. The `RawWakerVTable::new` can be const evaluated,
but `RawWaker::new` itself cannot since waker pointer is not known at compile
time. Add `#[inline]` to avoid overhead of a function call.
```rust
unsafe fn clone_waker<W: Wake + Send + Sync + 'static>(waker: *const ()) -> RawWaker {
unsafe { Arc::incr_strong_count(waker as *const W) };
RawWaker::new(
waker as *const (),
&RawWakerVTable::new(clone_waker::<W>, wake::<W>, wake_by_ref::<W>, drop_waker::<W>),
)
}
```
Update stdarch submodule
This commit updates the src/stdarch submodule primarily to include
rust-lang/stdarch#874 which updated and revamped WebAssembly SIMD
intrinsics and renamed WebAssembly atomics intrinsics. This is all
unstable surface area of the standard library so the changes should be
ok here. The SIMD updates also enable SIMD intrinsics to be used by any
program any any time, yay!
cc #74372, a tracking issue I've opened for the stabilization of SIMD
intrinsics
This commit updates the src/stdarch submodule primarily to include
rust-lang/stdarch#874 which updated and revamped WebAssembly SIMD
intrinsics and renamed WebAssembly atomics intrinsics. This is all
unstable surface area of the standard library so the changes should be
ok here. The SIMD updates also enable SIMD intrinsics to be used by any
program any any time, yay!
cc #74372, a tracking issue I've opened for the stabilization of SIMD
intrinsics
Improve defaults in x.py
- Make the default stage dependent on the subcommand
- Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want, use x.py build --stage 2 instead, which gives you a working libstd.
- Change default debuginfo when debug = true from 2 to 1
I tried to fix CI to use `--stage 2` everywhere it currently has no stage, but I might have missed a spot.
This does not update much of the documentation - most of it is in https://github.com/rust-lang/rustc-dev-guide/ or https://github.com/rust-lang/rust-forge and will need a separate PR.
See individual commits for a detailed rationale of each change.
See also the MCP: https://github.com/rust-lang/compiler-team/issues/326
r? @Mark-Simulacrum , but anyone is free to give an opinion.
config.toml.example: Update remap-debuginfo doc to be more general & accurate
This makes it more obvious that the work-around to #74786 is actually correct, and a custom `--remap-path-prefix` isn't needed.
In fact the previous comment `/rustc/$hash/$crate` was wrong, it is not `$crate` but whatever path exists in the rustc source tree, so either `src/$crate` or `vendor/$crate`. I've fixed that as well to avoid future confusion.
Separate `missing_doc_code_examples` from intra-doc links
These two lints have no relation other than both being nightly-only.
This allows stabilizing intra-doc links without stabilizing `missing_doc_code_examples`.
Fixes one of the issues spotted by @ollie27 in https://github.com/rust-lang/rust/pull/74430#issuecomment-664693080.
r? @Manishearth
- Use stage 2 for makefile
- Move assert to builder
- Don't add an assert for --help
- Allow --stage 0 if passed explicitly
- Don't assert defaults during tests
Otherwise it's impossible to test the defaults!
From [a conversation in discord](https://discordapp.com/channels/442252698964721669/443151243398086667/719200989269327882):
> Linking seems to consume all available RAM, leading to the OS to swap memory to disk and slowing down everything in the process
Compiling itself doesn't seem to take up as much RAM, and I'm only looking to check whether a minimal testcase can be compiled by rustc, where the runtime performance isn't much of an issue
> do you have debug = true or debuginfo-level = 2 in config.toml?
> if so I think that results in over 2GB of debuginfo nowadays and is likely the culprit
> which might mean we're giving out bad advice :(
Anecdotally, this sped up my stage 1 build from 15 to 10 minutes.
This still adds line numbers, it only removes variable and type information.
- Improve wording for debuginfo description
Co-authored-by: Teymour Aldridge <42674621+teymour-aldridge@users.noreply.github.com>
- Set rustc to build only when explicitly asked for
This allows building the stage2 rustc artifacts, which nothing depends
on.
Previously the behavior was as follows (where stageN <-> stage(N-1) artifacts, except for stage0 libstd):
- `x.py build --stage 0`:
- stage0 libstd
- stage1 rustc (but without putting rustc in stage0/)
This leaves you without any rustc at all except for the beta compiler
(https://github.com/rust-lang/rust/issues/73519). This is never what you want.
- `x.py build --stage 1`:
- stage0 libstd
- stage1 rustc
- stage1 libstd
- stage1 rustdoc
- stage2 rustc
This leaves you with a broken stage2 rustc which doesn't even have
libcore and is effectively useless. Additionally, it compiles rustc
twice, which is not normally what you want.
- `x.py build --stage 2`:
- stage0 libstd
- stage1 rustc
- stage1 libstd
- stage2 rustc
- stage2 rustdoc and tools
This builds all tools in release mode. This is the correct usage for CI,
but takes far to long for development.
Now the behavior is as follows:
- `x.py build --stage 0`:
- stage0 libstd
This is suitable for contributors only working on the standard library,
as it means rustc never has to be compiled.
- `x.py build --stage 1`:
- stage0 libstd
- stage1 rustc
- stage1 libstd
- stage1 rustdoc
This is suitable for contributors working on the compiler. It ensures
that you have a working rustc and libstd without having to pass
`src/libstd` in addition.
- `x.py build --stage 2`:
- stage0 libstd
- stage1 rustc
- stage1 libstd
- stage2 rustc
- stage2 libstd
- stage2 rustdoc
This is suitable for debugging errors which only appear with the stage2
compiler.
- `x.py build --stage 2 src/libstd src/rustc`
- stage0 libstd
- stage1 rustc
- stage1 libstd
- stage2 rustc
- stage2 libstd
- stage2 rustdoc, tools, etc.
- stage2 rustc artifacts ('stage3')
This is suitable for CI, which wants all tools in release mode.
However, most of the use cases for this should use `x.py dist` instead,
which builds all the tools without each having to be named individually.
### x.py build/test: stage 1
I've seen very few people who actually use full stage 2 builds on purpose. These compile rustc and libstd twice and don't give you much more information than a stage 1 build (except in rare cases like https://github.com/rust-lang/rust/pull/68692#discussion_r376392145). For new contributors, this makes the build process even more daunting than it already is. As long as CI is changed to use `--stage 2` I see no downside here.
### x.py bench/dist/install: stage 2
These commands have to do with a finished, optimized version of rustc. It seems very rare to want to use these with a stage 1 build.
### x.py doc: stage 0
Normally when you document things you're just fixing a typo. In this case there is no need to build the whole rust compiler, since the documentation will usually be the same when generated with the beta compiler or with stage 1.
Note that for this release cycle only there will be a significant different between stage0 and stage1 docs: https://github.com/rust-lang/rust/pull/73101. However most of the time this will not be the case.
