-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[beta] backports #135048
Merged
Merged
[beta] backports #135048
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When we encounter an error caused by traits/types of different versions of the same crate, filter out the current crate when collecting spans to add to the context so we don't call `extern_crate` on the `DefId` of the current crate, which is meaningless and ICEs. Produced output with this filter: ``` error[E0277]: the trait bound `foo::Struct: Trait` is not satisfied --> y.rs:13:19 | 13 | check_trait::<foo::Struct>(); | ^^^^^^^^^^^ the trait `Trait` is not implemented for `foo::Struct` | note: there are multiple different versions of crate `foo` in the dependency graph --> y.rs:7:1 | 4 | extern crate foo; | ----------------- one version of crate `foo` is used here, as a direct dependency of the current crate 5 | 6 | pub struct Struct; | ----------------- this type implements the required trait 7 | pub trait Trait {} | ^^^^^^^^^^^^^^^ this is the required trait | ::: x.rs:4:1 | 4 | pub struct Struct; | ----------------- this type doesn't implement the required trait 5 | pub trait Trait {} | --------------- this is the found trait = note: two types coming from two different versions of the same crate are different types even if they look the same = help: you can use `cargo tree` to explore your dependency tree note: required by a bound in `check_trait` --> y.rs:10:19 | 10 | fn check_trait<T: Trait>() {} | ^^^^^ required by this bound in `check_trait` ``` Fix rust-lang#133563. (cherry picked from commit 8574f37)
(cherry picked from commit e97e15d)
(cherry picked from commit 998ff2f)
(cherry picked from commit de16ed3)
(cherry picked from commit 9c4a61f)
(cherry picked from commit 2383985)
(cherry picked from commit c367cc3)
The "panic in const if CTFE doesn't know the answer" behavior was discussed to be the desired behavior in rust-lang#74939, and is currently how the function actually behaves. I intentionally wrote this documentation to allow for the possibility that a panic might not occur even if the pointer is out of bounds, because of rust-lang#133700 and other potential changes in the future. (cherry picked from commit 9388917)
(cherry picked from commit e6efbb2)
(cherry picked from commit 2e57394)
(cherry picked from commit 5e07901)
(cherry picked from commit b535061)
(cherry picked from commit 6564403)
- `cc` 1.2.4 contains a fix to address [rustc uses wrong build tools when compiling from MSVC rust-lang#133794](rust-lang#133794). See <https://github.com/rust-lang/cc-rs/releases/tag/cc-v1.2.4>. - `cc` 1.2.5 contains a fix to also check linking when testing if certain compiler flags are supported, which fixed an issue that was causing previous compiler `cc` bumps to fail. See <https://github.com/rust-lang/cc-rs/releases/tag/cc-v1.2.5>. Co-authored-by: David Lönnhager <[email protected]> (cherry picked from commit 3775d22)
(cherry picked from commit 42d1a4c)
Rustdoc has no way to show that an item is stable, but only at a different path. `std::ffi::c_str::NulError` is not stable, but `std::ffi::NulError` is. To avoid marking these types as unstable when someone just wants to follow a link from `CString`, inline them into their stable paths. (cherry picked from commit 40b0026)
(cherry picked from commit fc8a541)
(cherry picked from commit 11ad6ff)
rustbot
added
A-run-make
Area: port run-make Makefiles to rmake.rs
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
labels
Jan 2, 2025
@bors r+ p=1 rollup=never |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jan 2, 2025
☀️ Test successful - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-run-make
Area: port run-make Makefiles to rmake.rs
merged-by-bors
This PR was explicitly merged by bors.
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
extern_crate
on current trait on crate mismatch errors Do not callextern_crate
on current trait on crate mismatch errors #133585backwards_incompatible_lint
drops appropriately in drop elaboration Make sure we handlebackwards_incompatible_lint
drops appropriately in drop elaboration #134486cc
to 1.2.5 Bump compilercc
to 1.2.5 #134505DropKind::ForLint
in coroutines correctly HandleDropKind::ForLint
in coroutines correctly #134575std::ffi::c_str
types tostd::ffi
docs: inlinestd::ffi::c_str
types tostd::ffi
#134791alloc::ffi::c_str
types toalloc::ffi
docs: inlinealloc::ffi::c_str
types toalloc::ffi
#134851r? cuviper