Skip to content
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 18 commits into from
Jan 3, 2025
Merged

[beta] backports #135048

merged 18 commits into from
Jan 3, 2025

Conversation

cuviper
Copy link
Member

@cuviper cuviper commented Jan 2, 2025

r? cuviper

estebank and others added 18 commits January 2, 2025 13:43
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)
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 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)
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)
@rustbot 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
@cuviper
Copy link
Member Author

cuviper commented Jan 2, 2025

@bors r+ p=1 rollup=never

@bors
Copy link
Contributor

bors commented Jan 2, 2025

📌 Commit f72c836 has been approved by cuviper

It is now in the queue for this repository.

@bors 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
@bors
Copy link
Contributor

bors commented Jan 3, 2025

⌛ Testing commit f72c836 with merge 953a5ca...

@bors
Copy link
Contributor

bors commented Jan 3, 2025

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing 953a5ca to beta...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 3, 2025
@bors bors merged commit 953a5ca into rust-lang:beta Jan 3, 2025
7 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Jan 3, 2025
@cuviper cuviper deleted the beta-next branch January 10, 2025 23:47
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants