It's not needed, because `next` and `local` fields uniquely identify the
drop. This is a ~2% speed win on the very large program in #134404, and
it's also a tiny bit simpler.
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
rename internal panicking::try to catch_unwind
The public function is called `catch_unwind`, the intrinsic at some point got renamed to `catch_unwind` -- there's no reason to have the internal implementation of this still be called `try`, so let's rename it to match the rest.
additional edge cases tests for `path.rs` 🧪
This pull request adds a few new edge case tests to the `std::path` module. The new tests cover scenarios such as paths with only separators, non-ASCII and Unicode characters, embedded new lines, etc. Each new test is documented with some helpful in-line comments as well.
- 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
Use the fn_span when emitting function calls for better debug info.
This especially improves the developer experience for long chains of function calls that span multiple lines, which is common with builder patterns, chains of iterator/future combinators, etc.
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: arm-android
r? `@jieyouxu`
document some -Z flags as living in the rustc-dev-guide
i was looking for these but didn't find them at first; add a breadcrumb so people know where to look
refactor `CanonicalVarKind`
it's unnecessary. I don't believe we'll ever need to store additional info shared by all `CanonicalVarKind`s.
r? `@compiler-errors`
std: sys: net: uefi: Implement TCP4 connect
- Implement TCP4 connect using EFI_TCP4_PROTOCOL.
- Tested on QEMU setup with connecting to TCP server on host.
Guarantee behavior of transmuting `Option::<T>::None` subject to NPO
In https://github.com/rust-lang/rust/pull/115333, we added a guarantee that transmuting from `[0u8; N]` to `Option<P>` is sound where `P` is a pointer type subject to the null pointer optimization (NPO). It would be useful to be able to guarantee the inverse - that a `None::<P>` value can be transmutes to an array and that will yield `[0u8; N]`.
Closes#117591
Rollup of 7 pull requests
Successful merges:
- #141405 (GetUserProfileDirectoryW is now documented to always store the size)
- #141427 (Disable `triagebot`'s `glacier` handler)
- #141429 (Dont walk into unsafe binders when emiting error for non-structural type match)
- #141438 (Do not try to confirm non-dyn compatible method)
- #141444 (Improve CONTRIBUTING.md grammar and clarity)
- #141446 (Add 2nd Solaris target maintainer)
- #141456 (Suggest correct `version("..")` predicate syntax in check-cfg)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not try to confirm non-dyn compatible method
See the comment I left in `compiler/rustc_hir_typeck/src/method/confirm.rs`.
If we have a receiver that does not deref to the `dyn Trait` we're assembling the method from, then we used to ICE, but that's something that is possible to encounter with arbitrary self types.
r? oli-obk
Fixes https://github.com/rust-lang/rust/issues/141419
