[RISC-V] Do not force frame pointers
We have been seeing some very inefficient code that went away when using
`-Cforce-frame-pointers=no`. For instance `core::ptr::drop_in_place` at
`-Oz` was compiled into a function which consisted entirely of saving
registers to the stack, then using the frame pointer to restore the same
registers (without any instructions between the prolog and epilog).
The RISC-V LLVM backend supports frame pointer elimination, so it makes
sense to allow this to happen when using Rust. It's not clear to me that
frame pointers have ever been required in the general case.
In rust-lang/rust#61675 it was pointed out that this made reassembling
stack traces easier, which is true, but there is a code generation
option for forcing frame pointers, and I feel the default should not be
to require frame pointers, given it demonstrably makes code size worse
(around 10% in some embedded applications).
The kinds of targets mentioned in rust-lang/rust#61675 are popular, but
should not dictate that code generation should be worse for all RISC-V
targets, especially as there is a way to use CFI information to
reconstruct the stack when the frame pointer is eliminated. It is also
a misconception that `fp` is always used for the frame pointer. `fp` is
an ABI name for `x8` (aka `s0`), and if no frame pointer is required,
`x8` may be used for other callee-saved values.
---
I am partly posting this to get feedback from @fintelia who introduced the change to require frame pointers, and @hanna-kruppe who had issues with the original PR. I would understand if we wanted to remove this setting on only a subset of RISC-V targets, but my preference would be to remove this setting everywhere.
There are more details on the code size savings seen in Tock here: https://github.com/tock/tock/pull/1660
Update LLVM submodule
Only includes one commit:
- [D80759](https://reviews.llvm.org/D80759): Fix FastISel dropping srcloc metadata from InlineAsm
Fixes#40555
Rollup of 8 pull requests
Successful merges:
- #73237 (Check for overflow in DroplessArena and align returned memory)
- #73339 (Don't run generator transform when there's a TyErr)
- #73372 (Re-order correctly the sections in the sidebar)
- #73373 (Use track caller for bug! macro)
- #73380 (Add more info to `x.py build --help` on default value for `-j JOBS`.)
- #73381 (Fix typo in docs of std::mem)
- #73389 (Use `Ipv4Addr::from<[u8; 4]>` when possible)
- #73400 (Fix forge-platform-support URL)
Failed merges:
r? @ghost
Re-order correctly the sections in the sidebar
Before that, "trait implementations" and "implementors" titles in the sidebar were before "methods" for example. Which wasn't logical considering that the two sections come after in the "content".
r? @kinnison
Don't run generator transform when there's a TyErr
Not sure if this might cause any problems later on, but we shouldn't be hitting codegen or const eval for the produced MIR anyways, so it should be fine.
cc https://github.com/rust-lang/rust/issues/72685#issuecomment-643749020
Check for overflow in DroplessArena and align returned memory
* Check for overflow when calculating the slice start & end position.
* Align the pointer obtained from the allocator, ensuring that it
satisfies user requested alignment (the allocator is only asked for
layout compatible with u8 slice).
* Remove an incorrect assertion from DroplessArena::align.
* Avoid forming references to an uninitialized memory in DroplessArena.
Helps with #73007, #72624.
Avoid prematurely recording toolstates
When we're running with dry_run enabled (i.e. all builds do this initially), we're
guaranteed to save of a toolstate of TestFail for tools that aren't tested. In practice,
we do test tools as well, so for those tools we would initially record them as being
TestPass, and then later on re-record the correct state after actually testing them.
However, this would not work well if the build failed for whatever reason (e.g. panicking
in bootstrap, or as was the case in #73097, clippy failing to test successfully), we would
just go on believing that things passed when they in practice did not.
This commit also adjusts saving toolstate to never record clippy explicitly (otherwise, it
would be recorded when building it); eventually that'll likely move to other tools as well
but not yet. This is deemed simpler than checking everywhere we generically save
toolstate.
We also move clippy out of the "toolstate" no-fail-fast build into a separate x.py
invocation; this should no longer be technically required but provides the nice state of
letting us check toolstate for all tools and only then check clippy (giving full results
on every build).
r? @oli-obk
Supercedes #73275, also fixes#73274
store `ObligationCause` on the heap
Stores `ObligationCause` on the heap using an `Rc`.
This PR trades off some transient memory allocations to reduce the size of–and thus the number of instructions required to memcpy–a few widely used data structures in trait solving.
When we're running with dry_run enabled (i.e. all builds do this initially), we're
guaranteed to save of a toolstate of TestFail for tools that aren't tested. In practice,
we do test tools as well, so for those tools we would initially record them as being
TestPass, and then later on re-record the correct state after actually testing them.
However, this would not work well if the build failed for whatever reason (e.g. panicking
in bootstrap, or as was the case in 73097, clippy failing to test successfully), we would
just go on believing that things passed when they in practice did not.
This commit also adjusts saving toolstate to never record clippy explicitly (otherwise, it
would be recorded when building it); eventually that'll likely move to other tools as well
but not yet. This is deemed simpler than checking everywhere we generically save
toolstate.
We also move clippy out of the "toolstate" no-fail-fast build into a separate x.py
invocation; this should no longer be technically required but provides the nice state of
letting us check toolstate for all tools and only then check clippy (giving full results
on every build).
Implement new gdb/lldb pretty-printers
Reopened#60826
This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters).
The current state of lldb pretty-printers is poor, because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support, I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill, so I got rid of it.
The new pretty-printers have to support all types supported by current pretty-printers, and also support `Rc`, `Arc`, `Cell`, `Ref`, `RefCell`, `RefMut`, `HashMap`, `HashSet`.
Fixes#56252
Rollup of 10 pull requests
Successful merges:
- #72707 (Use min_specialization in the remaining rustc crates)
- #72740 (On recursive ADT, provide indirection structured suggestion)
- #72879 (Miri: avoid tracking current location three times)
- #72938 (Stabilize Option::zip)
- #73086 (Rename "cyclone" to "apple-a7" per changes in upstream LLVM)
- #73104 (Example about explicit mutex dropping)
- #73139 (Add methods to go from a nul-terminated Vec<u8> to a CString)
- #73296 (Remove vestigial CI job msvc-aux.)
- #73304 (Revert heterogeneous SocketAddr PartialEq impls)
- #73331 (extend network support for HermitCore)
Failed merges:
r? @ghost
Revert heterogeneous SocketAddr PartialEq impls
Originally added in #72239.
These lead to inference regressions (mostly in tests) in code that looks like:
```rust
let socket = SocketAddrV4::new(Ipv4Addr::new(127, 0, 0, 1), 8080);
assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
```
That compiles as of stable 1.44.0 but fails in beta with:
```console
error[E0284]: type annotations needed
--> src/main.rs:3:41
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
| ^^^^^ cannot infer type for type parameter `F` declared on the associated function `parse`
|
= note: cannot satisfy `<_ as std::str::FromStr>::Err == _`
help: consider specifying the type argument in the method call
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse::<F>().unwrap());
|
```
Closes#73242.
Remove vestigial CI job msvc-aux.
This CI job isn't really doing anything, so it seems prudent to remove it.
For some history:
* This was introduced in #48809 when the msvc job was split in two to keep it under 2 hours (oh the good old days). At the time, this check-aux job did a bunch of things:
* tidy
* src/test/pretty
* src/test/run-pass/pretty
* src/test/run-fail/pretty
* src/test/run-pass-valgrind/pretty
* src/test/run-pass-fulldeps/pretty
* src/test/run-fail-fulldeps/pretty
* Tidy was removed in #60777.
* run-pass and run-pass-fulldeps moved to UI in #63029
* src/test/pretty removed in #58140
* src/test/run-fail moved to UI in #71185
* run-fail-fulldeps removed in #51285
Over time through attrition, the job was left with one lonely thing: `src/test/run-pass-valgrind/pretty`. And of course, this wasn't actually running the "pretty" tests. The normal `run-pass-valgrind` tests ran, and then when it tried to run in "pretty" mode, all the tests were ignored because compiletest thought nothing had changed (apparently compiletest isn't fingerprinting the mode? Needs more investigation…). `run-pass-valgrind` is already being run as part of `x86_64-msvc-1`, so there's no need to run it here.
I've taken the liberty of removing `src/test/run-pass-valgrind/pretty` as a distinct test. I'm guessing from the other PR's that the pretty tests should now live in `src/test/pretty`, and that the team has moved away from doing pretty tests on other parts of the `src/test` tree.
Add methods to go from a nul-terminated Vec<u8> to a CString
Fixes#73100.
Doc tests have been written and the documentation on the error type
updated too.
I used `#[stable(feature = "cstring_from_vec_with_nul", since = "1.46.0")]` but I don't know if the version is correct.
Example about explicit mutex dropping
Fixes#67457.
Following the remarks made in #73074, I added an example on the main `Mutex` type, with a situation where there is mutable data and a computation result.
In my testing it is effectively needed to explicitly drop the lock, else it deadlocks.
r? @dtolnay because you were the one to review the previous PR.
Stabilize Option::zip
This PR stabilizes the following API:
```rust
impl<T> Option<T> {
pub fn zip<U>(self, other: Option<U>) -> Option<(T, U)>;
}
```
This API has real world usage as seen in <https://grep.app/search?q=-%3E%20Option%3C%5C%28T%2C%5Cs%3FU%5C%29%3E®exp=true&filter[lang][0]=Rust>.
The `zip_with` method is left unstably as this API is kinda niche
and it hasn't received much usage in Rust repositories on GitHub.
cc #70086
Miri: avoid tracking current location three times
Miri tracks the current instruction to execute in the call stack, but it also additionally has two `TyCtxtAt` that carry a `Span` that also tracks the current instruction. That is quite silly, so this PR uses `TyCtxt` instead, and then uses a method for computing the current span when a `TyCtxtAt` is needed. Having less redundant (semi-)global state seems like a good improvement to me. :D
To keep the ConstProp errors the same, I had to add the option to `error_to_const_error` to overwrite the span. Also for some reason this changes cycle errors a bit -- not sure if we are now better or worse as giving those queries the right span. (It is unfortunately quite easy to accidentally use `DUMMY_SP` by calling the query on a `TyCtxt` instead of a `TyCtxtAt`.)
r? @oli-obk @eddyb
Use min_specialization in the remaining rustc crates
This adds a lot of `transmute` calls to replace the unsound uses of specialization.
It's ugly, but at least it's honest about what's going on.
cc #71420, @RalfJung
Return a pointer from `alloc_raw` instead of a slice. There is no
practical use for slice as a return type and changing it to a pointer
avoids forming references to an uninitialized memory.
structural_match: non-structural-match ty closures
Fixes#73003.
This PR adds a `Closure` variant to `NonStructuralMatchTy` in `structural_match`, fixing an ICE which can occur when `impl_trait_in_bindings` is used with constants.
Fix iterator copied() documentation example code
The documentation for copied() gives example code with variable v_cloned instead of v_copied. This seems like a copy/paste error from cloned() and it would be clearer to use v_copied.
Display information about captured variable in `FnMut` error
Fixes#69446
When we encounter a region error involving an `FnMut` closure, we
display a specialized error message. However, we currently do not
tell the user which upvar was captured. This makes it difficult to
determine the cause of the error, especially when the closure is large.
This commit records marks constraints involving closure upvars
with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame'
a `ConstraintCategory::Return`, we additionall store
the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in
the path.
When generating an error message, we point to relevant spans if we have
closure upvar information available. We further customize the message if
an `async` closure is being returned, to make it clear that the captured
variable is being returned indirectly.
Stabilize vec::Drain::as_slice
and add `AsRef<[T]> for Drain<'_, T>`.
Tracking issue: #58957. Does not stabilize `slice::IterMut::as_slice` yet. cc @cuviper
This PR proposes stabilizing just the `vec::Drain::as_slice` part of that tracking issue.
My ultimate goal here: being able to use `for<T, I: Iterator<Item=T> + AsRef<[T]>> I` to refer to `vec::IntoIter`, `vec::Drain`, and eventually `array::IntoIter`, as an approximation of the set of by-value iterators that can be "previewed" as by-ref iterators. (Actually expressing that as a trait requires GAT.)
Fix trait alias inherent impl resolution
Fixes#60021 and fixes#72415.
Obviously, the fix was very easy, but getting started with the testing and debugging rust compiler was an interesting experience. Now I can cross it off my bucket list!
Explain move errors that occur due to method calls involving `self`
When calling a method that takes `self` (e.g. `vec.into_iter()`), the method receiver is moved out of. If the method receiver is used again, a move error will be emitted::
```rust
fn main() {
let a = vec![true];
a.into_iter();
a;
}
```
emits
```
error[E0382]: use of moved value: `a`
--> src/main.rs:4:5
|
2 | let a = vec![true];
| - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 | a.into_iter();
| - value moved here
4 | a;
| ^ value used here after move
```
However, the error message doesn't make it clear that the move is caused by the call to `into_iter`.
This PR adds additional messages to move errors when the move is caused by using a value as the receiver of a `self` method::
```
error[E0382]: use of moved value: `a`
--> vec.rs:4:5
|
2 | let a = vec![true];
| - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 | a.into_iter();
| ------------- value moved due to this method call
4 | a;
| ^ value used here after move
|
note: this function takes `self`, which moves the receiver
--> /home/aaron/repos/rust/src/libcore/iter/traits/collect.rs:239:5
|
239 | fn into_iter(self) -> Self::IntoIter;
```
TODO:
- [x] Add special handling for `FnOnce/FnMut/Fn` - we probably don't want to point at the unstable trait methods
- [x] Consider adding additional context for operations (e.g. `Shr::shr`) when the call was generated using the operator syntax (e.g. `a >> b`)
- [x] Consider pointing to the method parent (impl or trait block) in addition to the method itself.
