Contracts: diagnostic message for mismatched function return type points to `ensures` clause
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
When a function is annotated with a contracts::ensures clause, the compiler emits confusing error messages when the return expression's type mismatches the function's declared type. The messages point at the ensures clause and the internal contract_check_ensures function, instead of the offending expression in the function body.
I'm unsure as to whether the fix is easy (e.g. ensuring the right spans are used in the right places during lowering), or would require rethinking the lowering apporach.
Minimal reproducible examples:
- Implicit return expression
#[core::contracts::ensures(|_| { true })] fn foo() -> u32 { true } - Explicit "early" return
#[core::contracts::ensures(|_| { true })] fn foo() -> u32 { if true { return true } 0 }
Both these examples provide an identical output on the main branch:
error[E0308]: mismatched types
--> src/main.rs:3:1
|
3 | #[core::contracts::ensures(|_| { true })]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| expected `u32`, found `bool`
| arguments to this function are incorrect
|
note: function defined here
--> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/intrinsics/mod.rs:2709:14
|
2709 | pub const fn contract_check_ensures<C: Fn(&Ret) -> bool + Copy, Ret>(
| ^^^^^^^^^^^^^^^^^^^^^^
error[E0308]: mismatched types
--> src/main.rs:3:1
|
3 | #[core::contracts::ensures(|_| { true })]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `bool`
4 | fn foo() -> u32 {
| --- expected `u32` because of return type
For more information about this error, try `rustc --explain E0308`.
The former example demonstrates a regression introduced in #144438, whereas the latter did not work correctly even before that change, giving the following output:
error[E0308]: mismatched types
--> /Users/dawidl022/Development/rust/tests/ui/contracts/return-early-span.rs:10:16
|
LL | #[core::contracts::ensures(|_| { true })]
| ----------------------------------------- arguments to this function are incorrect
...
LL | return true;
| ^^^^ expected `u32`, found `bool`
|
note: function defined here
--> /rustc/FAKE_PREFIX/library/core/src/intrinsics/mod.rs:2692:14
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0308`.
The expected behaviour is that the presence of contract annotation on a function do not affect the emitted error messages for errors in the function body. E.g. for the examples above respectively:
error[E0308]: mismatched types
--> src/main.rs:4:5
|
3 | fn foo() -> u32 {
| --- expected `u32` because of return type
4 | true
| ^^^^ expected `u32`, found `bool`
For more information about this error, try `rustc --explain E0308`.
error[E0308]: mismatched types
--> src/main.rs:5:16
|
3 | fn foo() -> u32 {
| --- expected `u32` because of return type
4 | if true {
5 | return true
| ^^^^ expected `u32`, found `bool`
For more information about this error, try `rustc --explain E0308`.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the implicit-return and early-return examples with the contracts::ensures annotation, then compare their diagnostics with the expected output. Read the contract lowering code around the span handling and inspect the regression context from #144438, along with tests/ui/contracts/return-early-span.rs and library/core/src/intrinsics/mod.rs. Done means body type errors point to the offending return expression rather than the ensures clause or contract_check_ensures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100