interpret: do not force_allocate all return places
A while ago I cleaned up our `PlaceTy` a little, but as a side-effect of that, return places had to always be force-allocated. That turns out to cause quite a few extra allocations, and for a project we are doing where we marry Miri with a model checker, that means a lot of extra work -- local variables are just so much easier to reason about than allocations.
So, this PR brings back the ability to have the return place be just a local of the caller. To make this work cleanly I had to rework stack pop handling a bit, which also changes the output of Miri in some cases as the span for errors occurring during a particular phase of stack pop changed.
With these changes, a no-std binary with a function of functions that just take and return scalar types and that uses no pointers now does not move *any* local variables into memory. :)
r? `@oli-obk`
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#134696 (Implement `normalize_lexically`)
- rust-lang/rust#140539 (Simplify `attribute_groups`)
- rust-lang/rust#140863 ([rustdoc] Unify type aliases rendering with other ADT)
- rust-lang/rust#140936 (Clarify WTF-8 safety docs)
- rust-lang/rust#140952 (Specify that split_ascii_whitespace uses the same definition as is_ascii_whitespace)
- rust-lang/rust#141472 (Attempt to improve the `std::fs::create_dir_all` docs related to atomicity)
- rust-lang/rust#141502 (ci: move PR job x86_64-gnu-tools to codebuild)
- rust-lang/rust#141559 (const-check: stop recommending the use of rustc_allow_const_fn_unstable)
r? `@ghost`
`@rustbot` modify labels: rollup
const-check: stop recommending the use of rustc_allow_const_fn_unstable
I have seen way too many people see the compiler suggest this attribute and then just apply it without a second thought. This is bad. So let's just stop recommending it; for the rare case where someone needs it, they'll eventually ask us and that way we can be sure that it is truly needed. The dev-guide still also explains `rustc_allow_const_fn_unstable`.
Cc ``@rust-lang/wg-const-eval``
Attempt to improve the `std::fs::create_dir_all` docs related to atomicity
The original paragraph was added in rust-lang/rust#124520. It doesn't match the actual code logic. It says "function returns an error" if "the parent components" _(which also implies directories)_ "have been created already". The code is as follows:
e88e854634/library/std/src/fs.rs (L3146)e88e854634/library/std/src/fs.rs (L3160)
These lines suppress all errors if any path component is a directory. I've updated the paragraph to mirror this.
Clarify WTF-8 safety docs
This PR is a follow-up to PR #140159, which clarifies ~~two things~~:
- the WTF-8 safety comment [was confusing](https://github.com/rust-lang/rust/pull/140159#discussion_r2082766965), either surrogate condition is actually sufficient for safety, both are not required
- ~~the private `os_str::Slice` type name is easily confused with `std::slice`~~
~~Happy to bikeshed the `OsSlice` name, other alternatives are `OsStrSlice` and `StrSlice`. Now it's got a distinct name from `std::slice`, it's easy to search and replace.~~
cc ``@thaliaarchi`` ``@workingjubilee``
[rustdoc] Unify type aliases rendering with other ADT
Fixes#140739.
Better reviewed one commit at a time.
Just one thing I'm wondering: should we also render non-`repr` attributes? If so, I wonder if we shouldn't simply change `clean::TypeAlias` to contain the other ADT directly (`Struct`, `Enum` and `Union`) and remove the `TypeAlias::generics` field.
Can be done in a follow-up too.
cc ``@camelid``
r? ``@notriddle``
Implement `normalize_lexically`
Implements #134694
This is, I think, the most straightforward implementation I could do, which will hopefully more easily allow experimentation if we decide to change the design here.
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a Cranelift update and (thanks for beetrees) f16/f128 support.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Random nits
Two completely random commits that I didn't know where to integrate into another PR.
* Don't use the full type relation machinery to equate two regions (it's overkill).
* Add a comment that `select_in_new_trait_solver` shouldn't be used directly.
r? lcnr or reassign
Avoid extra path trimming in method not found error
Method errors have an extra check that force trim paths whenever the normal string is longer than 10 characters, which can be quite unhelpful when multiple items have the same name (for example an `Error`).
A user reported this force trimming as being quite unhelpful when they had a method error where the precise path of the `Error` mattered.
The code uses `tcx.short_string` already to get the normal path, which tries to be clever around trimming paths if necessary, so there is no reason for this extra force trimming.
bootstrap: clippy: set TESTNAME based on given paths
This addresses #104200 by setting the TESTNAME environment variable automatically based on the paths from run configs, marking a selected set of UI tests to be run.
Note that this does not filter out other unit tests using #[test].
Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING
The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change.
PR #81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`.
This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR #124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version.
The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`.
Pulled out of #141137.
Tracking issue: #64796
Implement `advance_by` via `try_fold` for `Sized` iterators
When `try_fold` is overriden, it is usually easier for compilers to optimize.
Example difference: https://iter.godbolt.org/z/z8cEfnKro
use `cfg_select!` to select the right `VaListImpl` definition
tracking issue: https://github.com/rust-lang/rust/issues/44930
Just a bit of cleanup really.
We could use `PhantomInvariantLifetime<'f>` (https://github.com/rust-lang/rust/issues/135806) to make it more precise what that `PhantomData<&'f mut &'f c_void>` marker is doing. I'm not sure how ready that feature is though, `@jhpratt` are these types good to use internally?
---
Some research into the lifetimes of `VaList` and `VaListImpl`:
It's easy to see why the lifetime of these types should not be extended, a `VaList` or `VaListImpl` escaping its function is a bad idea. I don't currently see why coercing the lifetime to a shorter lifetime is problematic though, but probably I just don't understand variance well enough to see it. The history does not provide much explanation:
- 08140878fe original implementation
- b9ea653aee adds `VaListImpl<'f>`, but it is only covariant in `'f`
- https://github.com/rust-lang/rust/pull/62639 makes `VaListImpl<'f>` invariant over `'f` (because `VaList<'a, 'f>` is already invariant over `'f`, but I think that is just an implementation detail?)
Beyond that I don't see how the lifetime situation can be simplified significantly, e.g. this function really needs `'copy` to be unconstrained.
```rust
/// Copies the `va_list` at the current location.
pub unsafe fn with_copy<F, R>(&self, f: F) -> R
where
F: for<'copy> FnOnce(VaList<'copy, 'f>) -> R,
{
let mut ap = self.clone();
let ret = f(ap.as_va_list());
// SAFETY: the caller must uphold the safety contract for `va_end`.
unsafe {
va_end(&mut ap);
}
ret
}
```
`@rustbot` label +F-c_variadic
r? `@workingjubilee`
Docs(lib): Fix `extract_if` docs
Various fixes to the documentation comments of the several `extract_if` collection methods available. It originally started with a small typo fix in `Vec`'s spotted when reading the 1.87 release notes, but then by looking at the others' for comparison in order to try determining what was the intended sentence, some inconsistencies were spotted. Therefore, some other changes are also proposed here to reduce these avoidable differences, going more and more nit-picky along the way. See the individual commits for more details about each change.
`@rustbot` label T-libs A-collections A-docs
More option optimization tests
I noticed that although adding a manual implementation for PartialOrd on Option in #122024, I didn't add a test so that we can easily check if this behavior has improved.
This also adds a couple of `should-fail` tests - this will allow us to remove these hacky implementations if upstream LLVM improves.
This addresses issue 104200 by setting the TESTNAME environment
variable automatically based on the paths from run configs,
marking a selected set of UI tests to be run.
Note that this does not filter out other unit tests using #[test].
Method errors have an extra check that force trim paths whenever the
normal string is longer than 10 characters, which can be quite unhelpful
when multiple items have the same name (for example an `Error`).
A user reported this force trimming as being quite unhelpful when they
had a method error where the precise path of the `Error` mattered.
The code uses `tcx.short_string` already to get the normal path, which
tries to be clever around trimming paths if necessary, so there is no
reason for this extra force trimming.
Cleanup CodegenFnAttrFlags
- Rename `USED` to `USED_COMPILER` to better reflect its behavior.
- Reorder some items to group the used and allocator flags together
- Renumber them without gaps
