-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add tests for normalize-docs
overflow errors
#91430
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
r? @jackh726 |
For context, when
and if it helps, this is the backtrace for the cycle error:
|
362d15a
to
9646f3f
Compare
This comment has been minimized.
This comment has been minimized.
This unfortunately is still giving an unsilenceable overflow error :(
9646f3f
to
18ddf8d
Compare
Overflow errors are treated differently than how other errors. This has been brought up before. It might be beneficial to change this behavior, but it is what it is for now. @bors r+ |
📌 Commit 18ddf8d has been approved by |
and I had trouble getting straight answers then, too :/ https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Make.20.60TypeFolder.3A.3Afold_*.60.20return.20.60Result.60.20compiler-team.23432/near/239300519 |
Ah haha. I completely didn't register you had brought it up 🤐 I haven't put a lot of thought into why we need to emit overflow errors regardless of "speculation" or not. Off the top of my head, we definitely should be careful about treating overflow errors the same as "not implemented for some reason" errors. Otherwise, you could end up with behavior that is different depending on recursion depth. But, that might be context-dependent. |
…askrgr Rollup of 5 pull requests Successful merges: - rust-lang#88502 (Add slice take methods) - rust-lang#91313 (expand: Turn `ast::Crate` into a first class expansion target) - rust-lang#91424 (Update LLVM with patches for better llvm-cov diagnostics) - rust-lang#91425 (Include lint errors in error count for `-Ztreat-err-as-bug`) - rust-lang#91430 (Add tests for `normalize-docs` overflow errors) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Make cycle errors recoverable In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation. In the past, `@jackh726` has said we need to be careful about overflow errors: rust-lang#91430 (comment) > Off the top of my head, we definitely should be careful about treating overflow errors the same as "not implemented for some reason" errors. Otherwise, you could end up with behavior that is different depending on recursion depth. But, that might be context-dependent. But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered. Helps with rust-lang#81091. r? `@lcnr` cc `@matthewjasper`
Make cycle errors recoverable In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation. In the past, ``@jackh726`` has said we need to be careful about overflow errors: rust-lang#91430 (comment) > Off the top of my head, we definitely should be careful about treating overflow errors the same as "not implemented for some reason" errors. Otherwise, you could end up with behavior that is different depending on recursion depth. But, that might be context-dependent. But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered. Helps with rust-lang#81091. r? ``@lcnr`` cc ``@matthewjasper``
Make cycle errors recoverable In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation. In the past, ```@jackh726``` has said we need to be careful about overflow errors: rust-lang#91430 (comment) > Off the top of my head, we definitely should be careful about treating overflow errors the same as "not implemented for some reason" errors. Otherwise, you could end up with behavior that is different depending on recursion depth. But, that might be context-dependent. But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered. Helps with rust-lang#81091. r? ```@lcnr``` cc ```@matthewjasper```
@b-naber do you understand why using
try_normalize_erasing_regions
doesn't silence these cycle errors? Rustdoc isn't emitting them, rustc is aborting before returning an error, even though the function hastry_
in the name.cc #82692, #91255