-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
error message when unit test type does not implement Termination
is ungreat
#50291
Comments
As long as we have the method signature around when we emit E0277, it has a field with the span for the return type, which should be used for this instead, but this will probably require some special casing this in that (already quite hairy) diagnostic code. Extending
|
Chiming in that this confused me as I was preparing for a Rust training session, where I expect it would confuse the students even more. Specifically, this should not talk about |
CC #60179 |
Just started learning Rust and came across this error while writing some tests- I absolutely agree "ungreat" is perfect word choice. |
It could get even more confusing when using use std::process::Termination;
fn foo<T: Termination>(_: T) {}
fn main() {
foo(1_i32);
}
Rust 1.64 |
Actually, let's keep this open only for the span change :) |
Just wrap the return type with a struct and implement the Termination trait for that wrapper struct
|
`#[test]`: Point at return type if `Termination` bound is unsatisfied Together with rust-lang#103142 (already merged) this fully fixes rust-lang#50291. I don't consider my current solution of changing a few spans “here and there” very clean since the failed obligation is a `FunctionArgumentObligation` and we point at a type instead of a function argument. If you agree with me on this point, I can offer to keep the spans of the existing nodes and instead inject `let _: AssertRetTyIsTermination<$ret_ty>;` (type to be defined in `libtest`) similar to `AssertParamIsEq` etc. used by some built-in derive-macros. I haven't tried that approach yet though and cannot promise that it would actually work out or be “cleaner” for that matter. `@rustbot` label A-libtest A-diagnostics r? `@estebank`
`#[test]`: Point at return type if `Termination` bound is unsatisfied Together with rust-lang#103142 (already merged) this fully fixes rust-lang#50291. I don't consider my current solution of changing a few spans “here and there” very clean since the failed obligation is a `FunctionArgumentObligation` and we point at a type instead of a function argument. If you agree with me on this point, I can offer to keep the spans of the existing nodes and instead inject `let _: AssertRetTyIsTermination<$ret_ty>;` (type to be defined in `libtest`) similar to `AssertParamIsEq` etc. used by some built-in derive-macros. I haven't tried that approach yet though and cannot promise that it would actually work out or be “cleaner” for that matter. ``@rustbot`` label A-libtest A-diagnostics r? ``@estebank``
`#[test]`: Point at return type if `Termination` bound is unsatisfied Together with rust-lang#103142 (already merged) this fully fixes rust-lang#50291. I don't consider my current solution of changing a few spans “here and there” very clean since the failed obligation is a `FunctionArgumentObligation` and we point at a type instead of a function argument. If you agree with me on this point, I can offer to keep the spans of the existing nodes and instead inject `let _: AssertRetTyIsTermination<$ret_ty>;` (type to be defined in `libtest`) similar to `AssertParamIsEq` etc. used by some built-in derive-macros. I haven't tried that approach yet though and cannot promise that it would actually work out or be “cleaner” for that matter. ```@rustbot``` label A-libtest A-diagnostics r? ```@estebank```
Edit: outstanding work is to change the span from pointing at the function body to point at the return type.
#50272 adds a test for the case where a unit test returns a value that does not implement
Termination
. The message currently talks aboutmain
and has an ugly multi-line span:The text was updated successfully, but these errors were encountered: