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

Add support for #[track_caller] #247

Closed
shepmaster opened this issue Jul 29, 2020 · 4 comments · Fixed by #306
Closed

Add support for #[track_caller] #247

shepmaster opened this issue Jul 29, 2020 · 4 comments · Fixed by #306
Labels
enhancement New feature or request feedback requested User feedback desired on a design decision good first issue Good for newcomers help wanted Extra attention is needed

Comments

@shepmaster
Copy link
Owner

This will involve adding a feature flag for Rust 1.46, then adding #[track_caller] to the context selector methods like build and fail.

@shepmaster shepmaster added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers feedback requested User feedback desired on a design decision labels Jul 29, 2020
@ctaggart
Copy link

I found the RFC at rust-lang/rfcs#2091. I think this is what I'm looking for. Yesterday, I ended up sprinkling code like this everywhere:

        let typ = ident(&alias_name.to_camel_case()).context(IdentError {
            file: file!(),
            line: line!(),
        })?;

It would be great if there was a variable like source that captured the caller automatically.

@shepmaster
Copy link
Owner Author

captured the caller automatically.

I have doubts about the true value of this. Why do you reuse an error type so frequently? Concretely speaking, why do you use IdentError in so many places that the file / line location is required to be able to make sense of a resulting error? If each context selector is used once, its name is already a unique identifier to locate the exact location of the problem.

@ctaggart
Copy link

ctaggart commented Nov 3, 2020

Thanks @shepmaster. I'd like to get to a point where each one is uniquely named, but it was easiest at first to wrap an error type generically. Well, until the error was thrown and I couldn't figure out the location.

@shepmaster
Copy link
Owner Author

Closed via #247

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feedback requested User feedback desired on a design decision good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants