Skip to content

Fix rustdoc ICE caused by mishandling of ambiguity errors - #162782

Merged
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
ShoyuVanilla:issue-162557
Oct 2, 2026
Merged

rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
ShoyuVanilla:issue-162557

Conversation

@ShoyuVanilla

@ShoyuVanilla ShoyuVanilla commented Sep 14, 2026 •

Copy link
Copy Markdown
Member

Fixes #162557

pub trait Service<Request> {
    type Future;
}

pub trait ZebraService<Request>: Service<Request> {}

impl<MaybeVerify, Request> ZebraService<Request> for MaybeVerify where
    MaybeVerify: Service<Request, Future: 'static>
{
}

pub struct Verifier;

impl Service<()> for Verifier {
    type Future = &'static ();
}

In the above minimization of the issue, when we try to check whether the blanket impl can be applied to Verifier,

let args = infcx.fresh_args_for_item(DUMMY_SP, item_def_id);
let impl_ty = ty.instantiate(tcx, args).skip_norm_wip();
let param_env = ty::ParamEnv::empty();
let impl_args = infcx.fresh_args_for_item(DUMMY_SP, impl_def_id);
let impl_trait_ref = trait_ref.instantiate(tcx, impl_args).skip_norm_wip();
// Require the type the impl is implemented on to match
// our type, and ignore the impl if there was a mismatch.
let Ok(eq_result) = infcx.at(&traits::ObligationCause::dummy(), param_env).eq(
DefineOpaqueTypes::Yes,
impl_trait_ref.self_ty(),
impl_ty,
) else {
continue;
};
let InferOk { value: (), obligations } = eq_result;
// FIXME(eddyb) ignoring `obligations` might cause false positives.
drop(obligations);
let clauses = tcx
.clauses_of(impl_def_id)
.instantiate(tcx, impl_args)
.clauses
.into_iter()
.map(Unnormalized::skip_norm_wip)

We make fresh args for the where-clause and skip normalization for it.

So, we have <?MaybeVerify as Service<?Request>>::Future: 'static bound to check. But it immediately evaluated into ambiguity due to stalled on infer vars in the fast path as the obligation contains the infer vars.

But due #162182 we evaluated it directly in the solver without stalled_on and this time it succeeded because we can normalize the alias into a concrete type &'static () and it outlives the static region.

So, I think it's very iffy to call InferCtxt::evaluate_obligation on a non-rigid alias and we should eagerly normalize it in L67 from the above rustdoc code.
But it may break something in rustdoc as normalizations inside it is pretty messy in general 🫠 So, I guess in another PR with crater runs.

r? lcnr

@rustbot

rustbot commented Sep 14, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

  • It's intentional.
  • The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @obi1kenobi

@rustbot rustbot added A-rustdoc-json Area: Rustdoc JSON backend 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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Sep 14, 2026
@ShoyuVanilla ShoyuVanilla changed the title Fix rustdoc ICE due to mishandling of ambiguity errors Fix rustdoc ICE caused by mishandling of ambiguity errors Sep 15, 2026
@lcnr

lcnr commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path:

<MaybeVerify as Service<?infer>>::Future: 'static should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases

This change is correct. Please separately do a PR to fix the type-outlives fastpath 😊

@bors r+ rollup

@rust-bors

rust-bors Bot commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 621507f has been approved by lcnr

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. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 30, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 1, 2026
Fix rustdoc ICE caused by mishandling of ambiguity errors

Fixes rust-lang#162557

```rust
pub trait Service<Request> {
    type Future;
}

pub trait ZebraService<Request>: Service<Request> {}

impl<MaybeVerify, Request> ZebraService<Request> for MaybeVerify where
    MaybeVerify: Service<Request, Future: 'static>
{
}

pub struct Verifier;

impl Service<()> for Verifier {
    type Future = &'static ();
}
```

In the above minimization of the issue, when we try to check whether the blanket impl can be applied to `Verifier`,

https://github.com/rust-lang/rust/blob/a8a1e6fd9df2e094d6f09c0d57991508680acc1c/src/librustdoc/clean/blanket_impl.rs#L42-L67

We make fresh args for the where-clause and skip normalization for it.

So, we have `<?MaybeVerify as Service<?Request>>::Future: 'static` bound to check. But it immediately evaluated into ambiguity due to stalled on infer vars in the fast path as the obligation contains the infer vars.

But due rust-lang#162182 we evaluated it directly in the solver without `stalled_on` and this time it succeeded because we can normalize the alias into a concrete type `&'static ()` and it outlives the static region.

So, I think it's very iffy to call `InferCtxt::evaluate_obligation` on a non-rigid alias and we should eagerly normalize it in `L67` from the above rustdoc code.
But it may break something in rustdoc as normalizations inside it is pretty messy in general 🫠 So, I guess in another PR with crater runs.

r? lcnr
rust-bors Bot pushed a commit that referenced this pull request Oct 1, 2026
…uwer

Rollup of 9 pull requests

Successful merges:

 - #163483 (Bump bootstrap compiler to 1.100.0 beta)
 - #161380 (only rerun const eval in next-solver if the const actually references opaques)
 - #162900 (Some refactorings around metadata encoding)
 - #163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`)
 - #163584 ([triagebot] Ping me for debugger visualizer changes)
 - #162782 (Fix rustdoc ICE caused by mishandling of ambiguity errors)
 - #163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`)
 - #163405 (Remove some #[linkage] options)
 - #163581 (do not suggest precise capturing when the opaque span is in a macro expansion)
@JonathanBrouwer

Copy link
Copy Markdown
Member

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #163595 (comment)

@rust-bors rust-bors Bot added 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 1, 2026
@rust-bors

rust-bors Bot commented Oct 1, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved.

This PR was contained in a rollup (#163595), which was unapproved.

View changes since this unapproval

@ShoyuVanilla

ShoyuVanilla commented Oct 2, 2026 •

Copy link
Copy Markdown
Member Author

💔 I suspect this PR failed tests as part of a rollup @bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #163595 (comment)

Sadage. It looks like one of the changed test in the rollup was affected by this again

@lcnr

lcnr commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

@bors r+

@rust-bors

rust-bors Bot commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

📌 Commit d85a18b has been tentatively approved by lcnr

It will be put into the queue for this repository once PR CI succeeds.

@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. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 2, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 2, 2026
Fix rustdoc ICE caused by mishandling of ambiguity errors

Fixes rust-lang#162557

```rust
pub trait Service<Request> {
    type Future;
}

pub trait ZebraService<Request>: Service<Request> {}

impl<MaybeVerify, Request> ZebraService<Request> for MaybeVerify where
    MaybeVerify: Service<Request, Future: 'static>
{
}

pub struct Verifier;

impl Service<()> for Verifier {
    type Future = &'static ();
}
```

In the above minimization of the issue, when we try to check whether the blanket impl can be applied to `Verifier`,

https://github.com/rust-lang/rust/blob/a8a1e6fd9df2e094d6f09c0d57991508680acc1c/src/librustdoc/clean/blanket_impl.rs#L42-L67

We make fresh args for the where-clause and skip normalization for it.

So, we have `<?MaybeVerify as Service<?Request>>::Future: 'static` bound to check. But it immediately evaluated into ambiguity due to stalled on infer vars in the fast path as the obligation contains the infer vars.

But due rust-lang#162182 we evaluated it directly in the solver without `stalled_on` and this time it succeeded because we can normalize the alias into a concrete type `&'static ()` and it outlives the static region.

So, I think it's very iffy to call `InferCtxt::evaluate_obligation` on a non-rigid alias and we should eagerly normalize it in `L67` from the above rustdoc code.
But it may break something in rustdoc as normalizations inside it is pretty messy in general 🫠 So, I guess in another PR with crater runs.

r? lcnr
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 2, 2026
…=lcnr

Fix `TypeOutlives` fast-path

> Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path:
>
> `<MaybeVerify as Service<?infer>>::Future: 'static` should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases
>
> This change is correct. Please separately do a PR to fix the type-outlives fastpath :blush:

_Originally posted by @lcnr in rust-lang#162782 (comment)

The first perf-run result is for always returning `Outcome::NoFastPath` on any infer var and the second one is for the current HEAD.

We shouldn't stall the outlives goal if the goal contains a non-rigid alias even though the goal contains a non-region infer. Non-fast path will normalize that non-rigid alias and that make the evaluation progress, and I think in theory the fast path shouldn't make observable difference outside the solver.

I'm not entirely sure on disabling fast path only in the presence of non-rigid opaques instead of disabling it entirely for non-region infer, but..

- It's no-less-correct than the status quo
- It roughly matches the actual non-fast path:
  https://github.com/rust-lang/rust/blob/dba8825fe50879b22129271fb865944e384f7cce/compiler/rustc_next_trait_solver/src/solve/mod.rs#L128-L129
- The later has some perf impact hard to ignore for `typenum`

I couldn't conjure up any case fixed by this PR other than the one in rust-lang#162782 😅

r? lcnr
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 2, 2026
Fix rustdoc ICE caused by mishandling of ambiguity errors

Fixes rust-lang#162557

```rust
pub trait Service<Request> {
    type Future;
}

pub trait ZebraService<Request>: Service<Request> {}

impl<MaybeVerify, Request> ZebraService<Request> for MaybeVerify where
    MaybeVerify: Service<Request, Future: 'static>
{
}

pub struct Verifier;

impl Service<()> for Verifier {
    type Future = &'static ();
}
```

In the above minimization of the issue, when we try to check whether the blanket impl can be applied to `Verifier`,

https://github.com/rust-lang/rust/blob/a8a1e6fd9df2e094d6f09c0d57991508680acc1c/src/librustdoc/clean/blanket_impl.rs#L42-L67

We make fresh args for the where-clause and skip normalization for it.

So, we have `<?MaybeVerify as Service<?Request>>::Future: 'static` bound to check. But it immediately evaluated into ambiguity due to stalled on infer vars in the fast path as the obligation contains the infer vars.

But due rust-lang#162182 we evaluated it directly in the solver without `stalled_on` and this time it succeeded because we can normalize the alias into a concrete type `&'static ()` and it outlives the static region.

So, I think it's very iffy to call `InferCtxt::evaluate_obligation` on a non-rigid alias and we should eagerly normalize it in `L67` from the above rustdoc code.
But it may break something in rustdoc as normalizations inside it is pretty messy in general 🫠 So, I guess in another PR with crater runs.

r? lcnr
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 2, 2026
…=lcnr

Fix `TypeOutlives` fast-path

> Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path:
>
> `<MaybeVerify as Service<?infer>>::Future: 'static` should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases
>
> This change is correct. Please separately do a PR to fix the type-outlives fastpath :blush:

_Originally posted by @lcnr in rust-lang#162782 (comment)

The first perf-run result is for always returning `Outcome::NoFastPath` on any infer var and the second one is for the current HEAD.

We shouldn't stall the outlives goal if the goal contains a non-rigid alias even though the goal contains a non-region infer. Non-fast path will normalize that non-rigid alias and that make the evaluation progress, and I think in theory the fast path shouldn't make observable difference outside the solver.

I'm not entirely sure on disabling fast path only in the presence of non-rigid opaques instead of disabling it entirely for non-region infer, but..

- It's no-less-correct than the status quo
- It roughly matches the actual non-fast path:
  https://github.com/rust-lang/rust/blob/dba8825fe50879b22129271fb865944e384f7cce/compiler/rustc_next_trait_solver/src/solve/mod.rs#L128-L129
- The later has some perf impact hard to ignore for `typenum`

I couldn't conjure up any case fixed by this PR other than the one in rust-lang#162782 😅

r? lcnr
rust-bors Bot pushed a commit that referenced this pull request Oct 2, 2026
…uwer

Rollup of 13 pull requests

Successful merges:

 - #163317 (Fix incremental compilation for fat LTO)
 - #163582 (Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs")
 - #151793 (Add mul_add_relaxed methods for floating-point types)
 - #162782 (Fix rustdoc ICE caused by mishandling of ambiguity errors)
 - #163010 (Miri can do dirfd now)
 - #163535 (Improve `DocStrings` perf)
 - #163576 (Fix `TypeOutlives` fast-path)
 - #163587 (Several small span improvements)
 - #163612 (fix `ValidateBoundVars`)
 - #163632 (bump rustc-build-sysroot)
 - #163635 (Revert note about signum of NaN)
 - #163644 (Add mailmap entry)
 - #163651 (Remove variants from `feature-gate-autodiff-use` test)
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 2, 2026
…=lcnr

Fix `TypeOutlives` fast-path

> Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path:
>
> `<MaybeVerify as Service<?infer>>::Future: 'static` should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases
>
> This change is correct. Please separately do a PR to fix the type-outlives fastpath :blush:

_Originally posted by @lcnr in rust-lang#162782 (comment)

The first perf-run result is for always returning `Outcome::NoFastPath` on any infer var and the second one is for the current HEAD.

We shouldn't stall the outlives goal if the goal contains a non-rigid alias even though the goal contains a non-region infer. Non-fast path will normalize that non-rigid alias and that make the evaluation progress, and I think in theory the fast path shouldn't make observable difference outside the solver.

I'm not entirely sure on disabling fast path only in the presence of non-rigid opaques instead of disabling it entirely for non-region infer, but..

- It's no-less-correct than the status quo
- It roughly matches the actual non-fast path:
  https://github.com/rust-lang/rust/blob/dba8825fe50879b22129271fb865944e384f7cce/compiler/rustc_next_trait_solver/src/solve/mod.rs#L128-L129
- The later has some perf impact hard to ignore for `typenum`

I couldn't conjure up any case fixed by this PR other than the one in rust-lang#162782 😅

r? lcnr
rust-bors Bot pushed a commit that referenced this pull request Oct 2, 2026
…uwer

Rollup of 14 pull requests

Successful merges:

 - #163582 (Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs")
 - #151793 (Add mul_add_relaxed methods for floating-point types)
 - #162782 (Fix rustdoc ICE caused by mishandling of ambiguity errors)
 - #163010 (Miri can do dirfd now)
 - #163535 (Improve `DocStrings` perf)
 - #163576 (Fix `TypeOutlives` fast-path)
 - #163587 (Several small span improvements)
 - #163603 (Reorganise reflection intrinsics)
 - #163612 (fix `ValidateBoundVars`)
 - #163632 (bump rustc-build-sysroot)
 - #163635 (Revert note about signum of NaN)
 - #163644 (Add mailmap entry)
 - #163647 (Rename `rustc_driver::run_compiler` to `compiler_entrypoint`)
 - #163651 (Remove variants from `feature-gate-autodiff-use` test)
@rust-bors
rust-bors Bot merged commit 0d66027 into rust-lang:main Oct 2, 2026
14 checks passed
@rustbot rustbot added this to the 1.101.0 milestone Oct 2, 2026
rust-bors Bot pushed a commit that referenced this pull request Oct 2, 2026
Rollup merge of #162782 - ShoyuVanilla:issue-162557, r=lcnr

Fix rustdoc ICE caused by mishandling of ambiguity errors

Fixes #162557

```rust
pub trait Service<Request> {
    type Future;
}

pub trait ZebraService<Request>: Service<Request> {}

impl<MaybeVerify, Request> ZebraService<Request> for MaybeVerify where
    MaybeVerify: Service<Request, Future: 'static>
{
}

pub struct Verifier;

impl Service<()> for Verifier {
    type Future = &'static ();
}
```

In the above minimization of the issue, when we try to check whether the blanket impl can be applied to `Verifier`,

https://github.com/rust-lang/rust/blob/a8a1e6fd9df2e094d6f09c0d57991508680acc1c/src/librustdoc/clean/blanket_impl.rs#L42-L67

We make fresh args for the where-clause and skip normalization for it.

So, we have `<?MaybeVerify as Service<?Request>>::Future: 'static` bound to check. But it immediately evaluated into ambiguity due to stalled on infer vars in the fast path as the obligation contains the infer vars.

But due #162182 we evaluated it directly in the solver without `stalled_on` and this time it succeeded because we can normalize the alias into a concrete type `&'static ()` and it outlives the static region.

So, I think it's very iffy to call `InferCtxt::evaluate_obligation` on a non-rigid alias and we should eagerly normalize it in `L67` from the above rustdoc code.
But it may break something in rustdoc as normalizations inside it is pretty messy in general 🫠 So, I guess in another PR with crater runs.

r? lcnr
rust-bors Bot pushed a commit that referenced this pull request Oct 2, 2026
Rollup merge of #163576 - ShoyuVanilla:outlives-fast-path, r=lcnr

Fix `TypeOutlives` fast-path

> Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path:
>
> `<MaybeVerify as Service<?infer>>::Future: 'static` should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases
>
> This change is correct. Please separately do a PR to fix the type-outlives fastpath :blush:

_Originally posted by @lcnr in #162782 (comment)

The first perf-run result is for always returning `Outcome::NoFastPath` on any infer var and the second one is for the current HEAD.

We shouldn't stall the outlives goal if the goal contains a non-rigid alias even though the goal contains a non-region infer. Non-fast path will normalize that non-rigid alias and that make the evaluation progress, and I think in theory the fast path shouldn't make observable difference outside the solver.

I'm not entirely sure on disabling fast path only in the presence of non-rigid opaques instead of disabling it entirely for non-region infer, but..

- It's no-less-correct than the status quo
- It roughly matches the actual non-fast path:
  https://github.com/rust-lang/rust/blob/dba8825fe50879b22129271fb865944e384f7cce/compiler/rustc_next_trait_solver/src/solve/mod.rs#L128-L129
- The later has some perf impact hard to ignore for `typenum`

I couldn't conjure up any case fixed by this PR other than the one in #162782 😅

r? lcnr
@rust-timer

Copy link
Copy Markdown
Collaborator

Note

This PR was benchmarked as part of triage of its containing rollup: triage URL.

Finished benchmarking commit (4f8baea): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.1% [0.1%, 0.1%] 3
Regressions ❌
(secondary)
0.3% [0.3%, 0.3%] 1
Improvements ✅
(primary)
-0.1% [-0.1%, -0.1%] 2
Improvements ✅
(secondary)
-0.3% [-0.5%, -0.1%] 3
All ❌✅ (primary) -0.0% [-0.1%, 0.1%] 5

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (primary 2.3%, secondary 4.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.3% [2.2%, 2.5%] 2
Regressions ❌
(secondary)
4.8% [2.7%, 6.9%] 8
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.3% [2.2%, 2.5%] 2

Binary size

Results (primary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.1%] 6
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [0.0%, 0.1%] 6

Bootstrap: missing data
Artifact size: 408.61 MiB -> 408.67 MiB (0.02%)

@rustbot rustbot added the perf-regression Performance regression. label Oct 2, 2026
@ShoyuVanilla
ShoyuVanilla deleted the issue-162557 branch October 3, 2026 04:58
flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request Oct 3, 2026
…uwer

Rollup of 14 pull requests

Successful merges:

 - rust-lang/rust#163582 (Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs")
 - rust-lang/rust#151793 (Add mul_add_relaxed methods for floating-point types)
 - rust-lang/rust#162782 (Fix rustdoc ICE caused by mishandling of ambiguity errors)
 - rust-lang/rust#163010 (Miri can do dirfd now)
 - rust-lang/rust#163535 (Improve `DocStrings` perf)
 - rust-lang/rust#163576 (Fix `TypeOutlives` fast-path)
 - rust-lang/rust#163587 (Several small span improvements)
 - rust-lang/rust#163603 (Reorganise reflection intrinsics)
 - rust-lang/rust#163612 (fix `ValidateBoundVars`)
 - rust-lang/rust#163632 (bump rustc-build-sysroot)
 - rust-lang/rust#163635 (Revert note about signum of NaN)
 - rust-lang/rust#163644 (Add mailmap entry)
 - rust-lang/rust#163647 (Rename `rustc_driver::run_compiler` to `compiler_entrypoint`)
 - rust-lang/rust#163651 (Remove variants from `feature-gate-autodiff-use` test)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-rustdoc-json Area: Rustdoc JSON backend perf-regression Performance regression. 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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ICE]: "did not expect successful goal when collecting ambiguity errors"

5 participants