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
No breaking changes for clippy in this update (which only impacts the
lint page).
The askama release information is
[here](https://github.com/askama-rs/askama/releases/tag/v0.14.0).
r? @samueltardieu
changelog: update askama version to `0.14.0`
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.
