Skip to content

Add #[track_caller] support to ? #77474

@yaahc

Description

@yaahc
Member

Right now if you construct an error via its Into implementation as provided by the blanket implementation in std it gives the following location.

Location:
   /home/jlusby/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/convert/mod.rs:545

We should add #[track_caller] to this trait and possibily some of the Try trait implementations so that errors that attempt to track their construction point can correctly point to user code.

cc @anp

Activity

added
C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
PG-error-handlingProject group: Error handling (https://github.com/rust-lang/project-error-handling)
on Oct 3, 2020
BGR360

BGR360 commented on Aug 27, 2021

@BGR360
Contributor

For reference this idea was mentioned also in #87401 (comment)

c410-f3r

c410-f3r commented on Mar 20, 2022

@c410-f3r
Contributor

Is there anything preventing this addition? If not, then I can create a PR

BGR360

BGR360 commented on Mar 21, 2022

@BGR360
Contributor

@c410-f3r Since my last comment in August, there has been further discussion about this in various places. IIRC, @yaahc resolved to add #[track_caller] to something, I think it was Into? That change might already be in. I'll go hunting in my notification history to see if I can find what I'm talking about.

BGR360

BGR360 commented on Mar 21, 2022

@BGR360
Contributor

It was to from_residual and it has been merged: #91752

Unless it has been since removed again, I think that means this issue can be closed?

c410-f3r

c410-f3r commented on Mar 21, 2022

@c410-f3r
Contributor

Thanks @BGR360

Unfortunately, such change did not prevent an error I am currently facing that also points stuff to ... library/core/src/convert/mod.rs.

Capture d’écran de 2022-03-21 19-05-04

But this can be reported in another issue with an appropriated reproducible snippet

yaahc

yaahc commented on Mar 21, 2022

@yaahc
MemberAuthor

I was worried it would still be broken, I remember in the past it losing the location when it went through Into and I thought I remembered ? desugaring to use Into but it looks like it uses From, so it seems to work fine for my small snippet using eyre.

use thiserror::Error;

fn main() {
    let err = inner().unwrap_err();
    println!("Error: {:?}", err);
}

#[derive(Debug, Error)]
#[error("my error")]
struct MyError;

fn inner() -> eyre::Result<()> {
    Err(MyError)?
}

It might be that original issue I was referring to was just about explicitly calling into in which case you can still reproduce the issue and I get:

Location:
    /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/convert/mod.rs:543:9

Which might be worth fixing, I'm not really sure. It would be a one line change and we'd need to perf test it but I'm not confident it would pass or be something we'd want to merge.

👍 @c410-f3r for opening a new issue for this specific issue. I'm gonna go ahead and close this one for now.

added a commit that references this issue on Jan 10, 2024
added a commit that references this issue on Jan 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-error-handlingArea: Error handlingC-feature-requestCategory: A feature request, i.e: not implemented / a PR.F-track_caller`#![feature(track_caller)]`PG-error-handlingProject group: Error handling (https://github.com/rust-lang/project-error-handling)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @yaahc@BGR360@c410-f3r@jyn514

        Issue actions

          Add #[track_caller] support to `?` · Issue #77474 · rust-lang/rust