Skip to content

Rollup of 4 pull requests - #162416

Closed
JonathanBrouwer wants to merge 10 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-gP9qL61
Closed

Rollup of 4 pull requests#162416
JonathanBrouwer wants to merge 10 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-gP9qL61

Conversation

@JonathanBrouwer

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost

Create a similar rollup

yara-blue and others added 10 commits August 27, 2026 16:27
This test demonstrates the existing crash, and will be migrated to a successful
coverage test in a subsequent commit.

Co-Authored-By: Rachel Barker <rachel.barker@ferrous-systems.com>
Compile-time-only functions don't generate code, so instrumenting them for
coverage is useless.

This also avoids an ICE when trying to get the function's symbol name for an
unused-function record, which can occur when instrumenting `core`.

Co-Authored-By: Rachel Barker <rachel.barker@ferrous-systems.com>
…dingxiangfei2009

Make Receiver `#[rustc_dyn_incompatible_trait]`

Fixes: rust-lang#149094

r? dingxiangfei2009
…y-slice, r=oli-obk

Remove fields from TypeKind: Array, Slice

Tracking issue rust-lang#146922

Part of the [Refactoring to many methods](https://rust-lang.zulipchat.com/#narrow/channel/572285-goals.2Freflection/topic/Refactoring.20to.20many.20methods/with/592226560) reflection subgoal. See that for the full context. In short for various reasons we are moving from an enum `TypeKind` where the variants hold the types information to one that just tells you the type kind. Separate methods on `TypeId` provide a way to get to the data that used to be in the variant.

r? @oli-obk
Make comptime functions ineligible for coverage

- rust-lang#159777
- rust-lang#161808
---

As reported in rust-lang#161808, the assertion in rust-lang#159777 causes the compiler to ICE when it tries to generate an unused-function record for comptime functions, because comptime functions aren't allowed to have a symbol name. This can occur when trying to instrument `core`, for example.

Compile-time-only functions don't generate code, so instrumenting them for coverage is useless anyway. This PR therefore makes them ineligible for coverage, which avoids the problem.
… r=oli-obk

add test ensuring we refuse to const-eval the body of a rustc_do_not_const_check function

IMO this is crucial, to ensure that we cannot break users by changing the body of such a function to something no-longer-const-compatible.

r? @oli-obk
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Sep 7, 2026
@rustbot rustbot added 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. labels Sep 7, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Member Author

@bors r+ p=5

@rust-bors

rust-bors Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 2fcd6d4 has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 7, 2026
@rust-bors

rust-bors Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

PR #162411, which is a member of this rollup, was unapproved.

This rollup was thus unapproved.

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 7, 2026
@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

The job test-aarch64-gnu-llvm-21-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
---- [ui] tests/ui/self/arbitrary-self-types-dyn-receiver.rs stdout ----

error: test compilation failed although it shouldn't!
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/self/arbitrary-self-types-dyn-receiver.rs" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "-O" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/self/arbitrary-self-types-dyn-receiver/a" "-Znext-solver=coherence" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
error[E0038]: the trait `std::ops::Receiver` is not dyn compatible
##[error]  --> /checkout/tests/ui/self/arbitrary-self-types-dyn-receiver.rs:12:5
   |
LL |     fn foo(self: &dyn Receiver<Target=Self>) {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `std::ops::Receiver` is not dyn compatible
   |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
  --> /rustc/FAKE_PREFIX/library/core/src/ops/deref.rs:370:0
   |
   = note: the trait is not dyn compatible because it opted out of dyn-compatibility

error[E0038]: the trait `std::ops::Receiver` is not dyn compatible
##[error]  --> /checkout/tests/ui/self/arbitrary-self-types-dyn-receiver.rs:12:18
   |
LL |     fn foo(self: &dyn Receiver<Target=Self>) {
   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ `std::ops::Receiver` is not dyn compatible
   |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
  --> /rustc/FAKE_PREFIX/library/core/src/ops/deref.rs:370:0
   |
   = note: the trait is not dyn compatible because it opted out of dyn-compatibility

error[E0038]: the trait `std::ops::Receiver` is not dyn compatible
##[error]  --> /checkout/tests/ui/self/arbitrary-self-types-dyn-receiver.rs:12:19
   |
LL |     fn foo(self: &dyn Receiver<Target=Self>) {
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^ `std::ops::Receiver` is not dyn compatible
   |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
  --> /rustc/FAKE_PREFIX/library/core/src/ops/deref.rs:370:0
   |
   = note: the trait is not dyn compatible because it opted out of dyn-compatibility
help: you might have meant to use `Self` to refer to the implementing type
   |
LL -     fn foo(self: &dyn Receiver<Target=Self>) {
LL +     fn foo(self: &Self) {
   |

error[E0038]: the trait `std::ops::Receiver` is not dyn compatible
##[error]  --> /checkout/tests/ui/self/arbitrary-self-types-dyn-receiver.rs:7:18
   |
LL |     fn foo(self: &dyn Receiver<Target=Self>);
   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ `std::ops::Receiver` is not dyn compatible
   |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
  --> /rustc/FAKE_PREFIX/library/core/src/ops/deref.rs:370:0
   |
   = note: the trait is not dyn compatible because it opted out of dyn-compatibility

error[E0038]: the trait `std::ops::Receiver` is not dyn compatible
##[error]  --> /checkout/tests/ui/self/arbitrary-self-types-dyn-receiver.rs:7:19
   |
LL |     fn foo(self: &dyn Receiver<Target=Self>);
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^ `std::ops::Receiver` is not dyn compatible
   |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
  --> /rustc/FAKE_PREFIX/library/core/src/ops/deref.rs:370:0
   |
   = note: the trait is not dyn compatible because it opted out of dyn-compatibility
help: you might have meant to use `Self` to refer to the implementing type
   |
LL -     fn foo(self: &dyn Receiver<Target=Self>);
LL +     fn foo(self: &Self);
   |

error[E0038]: the trait `std::ops::Receiver` is not dyn compatible
##[error]  --> /checkout/tests/ui/self/arbitrary-self-types-dyn-receiver.rs:19:17
   |
LL |     let y: &dyn Receiver<Target=Thing> = &x;
   |                 ^^^^^^^^^^^^^^^^^^^^^^ `std::ops::Receiver` is not dyn compatible
   |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
  --> /rustc/FAKE_PREFIX/library/core/src/ops/deref.rs:370:0
   |

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollup A PR which is a rollup 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants