minor `*dyn` cast cleanup
Small follow-up to https://github.com/rust-lang/rust/pull/130234 to remove a redundant check and clean up comments. No functional changes.
Also, explain why casts cannot drop the principal even though coercions can, and add a test because apparently we didn't have one already.
r? `@WaffleLapkin` or `@compiler-errors`
Deeply normalize `TypeTrace` when reporting type error in new solver
Normalize the values that come from the `TypeTrace` for various type mismatches.
Side-note: We can't normalize the `TypeError` itself bc it may come from instantiated binders, so it may reference values from within the probe...
r? lcnr
Fix `target_vendor` in QNX Neutrino targets
The `x86_64-pc-nto-qnx710` and `i586-pc-nto-qnx700` targets have `pc` in their target triple names, but the vendor was set to the default `"unknown"`.
CC target maintainers `@flba-eb,` `@gh-tr,` `@jonathanpallant` and `@japaric`
Rename Receiver -> LegacyReceiver
As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait.
This PR renames the old trait to get it out the way. Naming is hard. Options considered included:
* HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver
These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether.
Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages.
It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency.
This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519https://github.com/rust-lang/rust/issues/44874
r? `@wesleywiser`
Rollup of 9 pull requests
Successful merges:
- #130991 (Vectorized SliceContains)
- #131928 (rustdoc: Document `markdown` module.)
- #131955 (Set `signext` or `zeroext` for integer arguments on RISC-V and LoongArch64)
- #131979 (Minor tweaks to `compare_impl_item.rs`)
- #132036 (Add a test case for #131164)
- #132039 (Specialize `read_exact` and `read_buf_exact` for `VecDeque`)
- #132060 ("innermost", "outermost", "leftmost", and "rightmost" don't need hyphens)
- #132065 (Clarify documentation of `ptr::dangling()` function)
- #132066 (Fix a typo in documentation of `pointer::sub_ptr()`)
r? `@ghost`
`@rustbot` modify labels: rollup
"innermost", "outermost", "leftmost", and "rightmost" don't need hyphens
These are all standard dictionary words and don't require hyphenation.
-----
Encountered an instance of this in error messages and it bugged me, so I
figured I'd fix it across the entire codebase.
Add a test case for #131164
The upstream has already been fixed, but it won't be backported to LLVM 19.
r? jieyouxu or compiler
try-job: x86_64-gnu-stable
Minor tweaks to `compare_impl_item.rs`
1. Stop using the `InstantiatedPredicates` struct for `hybrid_preds` in `compare_impl_item.rs`, since we never actually push anything into the `spans` part of it.
2. Remove redundant impl args and don't do useless identity substitution, prefer calling `instantiate_identity`.
Set `signext` or `zeroext` for integer arguments on RISC-V and LoongArch64
This PR contains 3 commits:
- the first one introduces a new function `adjust_for_rust_abi` in `rustc_target`, and moves the x86 specific adjustment code into it;
- the second one adds RISC-V specific adjustment code into it, which sets `signext` or `zeroext` attribute for integer arguments.
- **UPDATE**: added the 3rd commit to apply the same adjustment for LoongArch64.
rustdoc: Document `markdown` module.
Rustdoc markdown handling is currently split between:
- html::markdown, which contains all the meaty login
- markdown, which is only used for when rustdoc renders a standalone markdown file
Adds module-level doc-comment to markdown, and rename the function so it's clear that it's doing IO (instead of just rendering to a string).
CI: rfl: use rust-next temporary commit
Commit c95bbb59a9b22f9b838b15d28319185c1c884329 within rust-next contains some changes required to be compatible with upcoming arbitraty self types work. Roll RFL CI forward to the latest rust-next to include that work.
Related:
https://github.com/rust-lang/rust/pull/130225https://github.com/rust-lang/rust/issues/44874
r? ``@ojeda``
try-job: x86_64-rust-for-linux
do not remove `.cargo` directory
If vendoring isn't used bootstrap removes `.cargo` directory, which prevents developers from setting certain options in the `.cargo/config.toml` file. This was introduced in https://github.com/rust-lang/rust/pull/97513 (specifically in [this commit](345eb14f6c)). Also, since https://github.com/rust-lang/rust/pull/123942, vendoring is now possible even in git sources, which means we shouldn't remove `.cargo` directory in git sources anymore.
Add wasm32v1-none target (compiler-team/#791)
This is a preliminary implementation of the MCP discussed in [compiler-team#791](https://github.com/rust-lang/compiler-team/issues/791). It's not especially "major" but you know, process! Anyway it adds a new wasm32v1-none target which just pins down a set of wasm features. I think this is close to the consensus that emerged when discussing it on Zulip so I figured I'd sketch to see how hard it is. Turns out not very.
Compiletest: Custom differ
This adds support for a custom differ for compiletests. It’s purely visual and helps produce cleaner output when UI tests fail.
I’m using an environment variable for now since it’s experimental and I don’t want to drill the cli arguments all the way down. Also did a bit of general cleanup while I was at it.
This is how it looks [with debug info silenced](https://github.com/rust-lang/rust/pull/131182) (#131182)
`COMPILETEST_DIFF_TOOL="/usr/bin/env difft --color always --background light --display side-by-side" ./x test tests/ui/parser`
Refactor change detection for rustdoc and download-rustc
This pull request refactors the change detection logic in the build process by consolidating redundant code into a new helper method. The key changes include the removal of duplicate logic for checking changes in directories and the addition of a new method to handle this functionality.
Refactoring and code simplification:
* [`src/bootstrap/src/core/build_steps/tool.rs`](diffhunk://#diff-dc86e288bcf7b3ca3f8c127d3568fbafc785704883bc7fc336bd185910aed5daL588-R593): Removed redundant change detection logic and replaced it with a call to the new `check_for_changes` method.
* [`src/bootstrap/src/core/config/config.rs`](diffhunk://#diff-5f5330cfcdb0a89b85ac3547b761c3a45c2534a85c4aaae8fea88c711a7a65b2R2837-R2872): Added a new method `check_for_changes` to centralize the logic for detecting changes in specified directories since a given commit.
* [`src/bootstrap/src/core/config/config.rs`](diffhunk://#diff-5f5330cfcdb0a89b85ac3547b761c3a45c2534a85c4aaae8fea88c711a7a65b2L2728-R2740): Updated the existing change detection code to use the new `check_for_changes` method.
Cleanup:
* [`src/bootstrap/src/core/build_steps/tool.rs`](diffhunk://#diff-dc86e288bcf7b3ca3f8c127d3568fbafc785704883bc7fc336bd185910aed5daL13-R13): Removed the unused import `git` from the helpers module.
r? ``@AlbertLarsan68``
nightly feature tracking: get rid of the per-feature bool fields
The `struct Features` that tracks which features are enabled has a ton of public `bool`-typed fields that are basically caching the result of looking up the corresponding feature in `enabled_lang_features`. Having public fields with an invariant is not great, so at least they should be made private. However, it turns out caching these lookups is actually [not worth it](https://github.com/rust-lang/rust/pull/131321#issuecomment-2402068336), so this PR just entirely gets rid of these fields. (The alternative would be to make them private and have a method for each of them to expose them in a read-only way. Most of the diff of this PR would be the same in that case.)
r? `@nnethercote`
do not implement `Relate` for "boring" types
and update some macros while we're at it. This means we don't have to implement `TypeVisitable` for them.
r? `@compiler-errors`
