Skip to content
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

Confusing error message for lifetime mismatch #132749

Closed
Kushagra-0801 opened this issue Nov 7, 2024 · 1 comment · Fixed by #133858
Closed

Confusing error message for lifetime mismatch #132749

Kushagra-0801 opened this issue Nov 7, 2024 · 1 comment · Fixed by #133858
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Kushagra-0801
Copy link

Kushagra-0801 commented Nov 7, 2024

Code

use bytes::Bytes;

#[allow(unused)]
struct SimpleString(Bytes);

fn deserialize_simple_string(buf: &[u8]) -> Result<(SimpleString, &[u8]), &'static str> {
    let Some((s, rest)) = split_on_crlf(buf) else {
        return Err("No CRLF found");
    };
    Ok((SimpleString(Bytes::from(s)), rest))
}


fn split_on_crlf(buf: &[u8]) -> Option<(&[u8], &[u8])> {
    let pos = buf.windows(2).position(|win| win == b"\r\n")?;
    let part = &buf[..pos];
    let rest = &buf[pos + 2..];
    Some((part, rest))
}

fn main() {
    let x = Vec::from(b"non-static user data\r\n");
    let _ = deserialize_simple_string(&x).unwrap();
}

Current output

error[E0521]: borrowed data escapes outside of function
 --> src/main.rs:7:27
  |
6 | fn deserialize_simple_string(buf: &[u8]) -> Result<(SimpleString, &[u8]), &'static str> {
  |                              ---  - let's call the lifetime of this reference `'1`
  |                              |
  |                              `buf` is a reference that is only valid in the function body
7 |     let Some((s, rest)) = split_on_crlf(buf) else {
  |                           ^^^^^^^^^^^^^^^^^^
  |                           |
  |                           `buf` escapes the function body here
  |                           argument requires that `'1` must outlive `'static`

Desired output

main.rs:23

In main()

`x` does not live for `'static` but `deserialize_simple_string` expects the argument to outlive `'static`.

Rationale and extra context

The real problem is that the Bytes::from implementation is only for &'static [u8]. Whatever the output is, it shouldn't be pointing to split_on_crlf as the culprit. I also don't see how it could be leaking the reference at all.

Playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=631eaea4377ffad8120532ea9e356233

Other cases

No response

Rust Version

Its the stable channel, debug build, 2021 edition on playground. Version 1.82.0

Anything else?

No response

@Kushagra-0801 Kushagra-0801 added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 7, 2024
@jieyouxu jieyouxu added the D-confusing Diagnostics: Confusing error or lint that should be reworked. label Nov 8, 2024
@dianne
Copy link
Contributor

dianne commented Nov 27, 2024

@rustbot claim

bors added a commit to rust-lang-ci/rust that referenced this issue Dec 4, 2024
…static, r=<try>

`best_blame_constraint`: Blame better constraints when failing to outlive `'static`

This fixes rust-lang#132749 by changing which constraint is blamed for region errors when failing to prove a region outlives `'static`. The comments give a better explanation, but very roughly, all the `'static: R` edges in the region graph made `best_blame_constraint` consider every constraint (other than those from ascriptions, returns, and yields) uninteresting to point to, so it chose semi-randomly based on an ordering of how interesting each variant of `ConstraintCategory` is expected to be. This PR (admittedly hackily) makes it ignore all those edges, so that the existing logic works the same as it would when failing to outlive any other region.

Looking at UI test diffs, most of them that changed I think changed for the better. Unfortunately, since a lot of borrowck's diagnostics depend on exactly which constraint is blamed, some things broke. A list of what I'm not happy with:
- For `CopyBound` constraints, e.g. [`tests/ui/nll/do-not-ignore-lifetime-bounds-in-copy.stderr`](https://github.com/rust-lang/rust/compare/master...dianne:rust:better-blame-constraints-for-static?expand=1#diff-e220f1e433c5e48d9afd431787f6ff27fc66b653762ee8a0283e370c2d88e7d0), I think it's helpful to surface that the `Copy` impl introduces the bound. If this is an issue, maybe it's worth prioritizing it or adding a variant of `ExtraConstraintInfo` for it.
- Likewise for `UseAsConst` and `UseAsStatic`; I've already added a special case for those. Without a special case, this was blaming `CallArgument` in [`tests/ui/consts/const-mut-refs/mut_ref_in_final.stderr`](https://github.com/dianne/rust/blob/189b2f892e6d0809a77fc92fe1108a07d8de9be0/tests/ui/consts/const-mut-refs/mut_ref_in_final.stderr#L38), which seemed pretty egregious. I'm assuming we want to blame `UseAsConst`/`UseAsStatic` when possible, rather than add something to `ExtraConstraintInfo`, since it's pretty unambiguously to-blame for "outlives `'static`" constraints. The special-casing admittedly also changes the output for [`tests/ui/inline-const/const-match-pat-lifetime-err.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:better-blame-constraints-for-static?expand=1#diff-e4d2c147aa96dd8dd963ec3d98ead9a8096c9de809d19ab379be3c53951ca1ca), but I think the new output there is fine; it's more direct about how `'a` and `'static` are getting related.
- The subdiagnostic [`BorrowExplanation::add_object_lifetime_default_note`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/diagnostics/explain_borrow/enum.BorrowExplanation.html#method.add_object_lifetime_default_note) depends on `Cast` being reported as the constraint category, so I've added a special case for it to keep it disappearing from [`tests/ui/traits/trait-object-lifetime-default-note.stderr`](https://github.com/dianne/rust/blob/better-blame-constraints-for-static/tests/ui/traits/trait-object-lifetime-default-note.stderr)[^1] . As I've outlined in a `FIXME` comment though, I think that subdiagnostic needs changing. There's multiple cases throughout `tests/ui` where it would be helpful, but doesn't fire, because a different constraint is picked. rust-lang#131008 would also benefit from that note, but there's not a coercion there at all. I tried making it fire in more cases, but fundamentally, since it doesn't *actually* check if an object lifetime default was used in the HIR, it produced some extraneous notes[^2]. I tried seeing if it'd be easy enough to fix that first, but it seems nontrivial[^3] enough to warrant a separate PR.

A final note: this may have perf consequences, since `best_blame_constraint` gets called on happy code too. If it's an issue, I can try to make it faster, or only do the expensive stuff when an error's been hit, or something. If nothing else, this makes the fallback logic (still relevant for invariant lifetimes[^4]) a bit faster.

[^1]: Incidentally, without the special-casing, this would pick `CallArgument`, which I think produces a nicer message, apart from the missing note.

[^2]: There's even some in current UI test output: [`tests/ui/borrowck/two-phase-surprise-no-conflict.stderr`](https://github.com/rust-lang/rust/blob/733616f7236b4be140ce851a30b3bb06532b9364/tests/ui/borrowck/two-phase-surprise-no-conflict.stderr#L68). The object lifetime is [explicitly provided](https://github.com/rust-lang/rust/blob/733616f7236b4be140ce851a30b3bb06532b9364/tests/ui/borrowck/two-phase-surprise-no-conflict.rs#L94), and despite the note, it's not `'static`.

[^3]: In case anyone reading this has advice: ultimately I think there has to be a choice between extraneous notes and missing notes unless "this object type had a missing lifetime in the HIR" is in crate metadata for some reason, since rustdoc doesn't elaborate object lifetime defaults, and the note is potentially helpful for library-users who may be wondering where a `'static` lifetime came from. That said, it's a bit confusing to point out lifetime defaults when they're not relevant[^5], so it's at least worth a best effort to look at user annotations. However, the HIR missing an object lifetime could be anywhere: a cast, an ascription, in the return type, in an input, in the signature for a function that's called, in an ADT field, in a type alias... I've considered looking at the entire output of `RegionInferenceContext::find_constraint_path_between_regions` and doing a best-effort association between typeck results (ideally MIR typeck for the region information) and whatever HIR seems relevant. But that seems like a lot of work for that note.

[^4]: Cycles in the region graph due to invariance also confuse `better_blame_constraint`'s attempt to pick a constraint where the regions aren't unified. I'm not sure if there's a better heuristic to use there, though; I played around a bit with it, but my experiments only made diagnostic output worse.

[^5]: Unless maybe there's a way of rewording the note so that it always makes sense to output when object lifetimes are involved in region errors?
@bors bors closed this as completed in 6afee11 Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
3 participants