rustdoc: Don't panic on ambiguous inherent associated types#88573
Merged
bors merged 1 commit intorust-lang:masterfrom Sep 2, 2021
Merged
rustdoc: Don't panic on ambiguous inherent associated types#88573bors merged 1 commit intorust-lang:masterfrom
bors merged 1 commit intorust-lang:masterfrom
Conversation
Instead, return `Type::Infer` since compilation should fail anyway. That's how rustdoc handles `hir::TyKind::Err`s, so this just extends that behavior to `ty::Err`s when analyzing associated types. For some reason, the error is printed twice with rustdoc (though only once with rustc). I'm not sure why that is, but it's better than panicking. This commit also makes rustdoc fail early in the non-projection, non-error case, instead of returning a `Res::Err` that would likely cause rustdoc to panic later on. This change is originally from rust-lang#88379.
Member
|
@bors: r+ |
Collaborator
|
📌 Commit 50983ba has been approved by |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 2, 2021
Rollup of 12 pull requests Successful merges: - rust-lang#88177 (Stabilize std::os::unix::fs::chroot) - rust-lang#88505 (Use `unwrap_unchecked` where possible) - rust-lang#88512 (Upgrade array_into_iter lint to include Deref-to-array types.) - rust-lang#88532 (Remove single use variables) - rust-lang#88543 (Improve closure dummy capture suggestion in macros.) - rust-lang#88560 (`fmt::Formatter::pad`: don't call chars().count() more than one time) - rust-lang#88565 (Add regression test for issue 83190) - rust-lang#88567 (Remove redundant `Span` in `QueryJobInfo`) - rust-lang#88573 (rustdoc: Don't panic on ambiguous inherent associated types) - rust-lang#88582 (Implement rust-lang#88581) - rust-lang#88589 (Correct doc comments inside `use_expr_visitor.rs`) - rust-lang#88592 (Fix ICE in const check) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Instead, return
Type::Infersince compilation should fail anyway.That's how rustdoc handles
hir::TyKind::Errs, so this just extendsthat behavior to
ty::Errs when analyzing associated types.For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.
This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a
Res::Errthat would likelycause rustdoc to panic later on. This change is originally from #88379.
r? @GuillaumeGomez