Intrinsics are not real functions and as such don't have any calling
convention. Trying to compute a calling convention for an intrinsic
anyway is a nonsensical operation.
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``
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.
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
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 `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`
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`
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
Dont walk into unsafe binders when emiting error for non-structural type match
Fixes#141422.
The other two binder-having types are also special cased here, unsurprisingly.
r? oli-obk
