How to verify that miette runs successfully for library mode

[BppleMan]

All examples do not describe the use of unit tests and integrate tests.

Which is required for #[source]#[source_code]#[source_from]#[diagnostic_source]?

I need to manually copy the source code myself and bind to the #[source] attribute?

I spent the whole night learning, but still didn't get started, just copied example to get a hard to call full example.

[zkat]

if you want to make sure that everything is working in library mode, I would test directly against the miette Diagnostic protocol: https://github.com/zkat/miette/blob/main/src/protocol.rs#L17-L67

That is, instead of checking how things render, I would make sure that each of these returns what you expect them to return, when you return your library's Error type. Does that make sense?

[BppleMan]

if you want to make sure that everything is working in library mode, I would test directly against the miette Diagnostic protocol: https://github.com/zkat/miette/blob/main/src/protocol.rs#L17-L67

That is, instead of checking how things render, I would make sure that each of these returns what you expect them to return, when you return your library's Error type. Does that make sense?

I think I'm expressing it wrong.

I'm developing a library, and I'm wrapping all errors in my library into a unified Error according to the example guide.

I write integration tests for my library, bugs are unavoidable during development, and I still want some fancy backtrace to be printed out in the integration tests as well to provide enough information for me to be picky eaters

[BppleMan]

#[derive(Debug, Error, Diagnostic)]
#[error("oops!")]
struct DemoError {
    #[source_code]
    pub src: NamedSource,
    #[label("This bit here")]
    pub bad_bit: SourceSpan,
}

fn third() -> FancyResult {
    Err(DemoError {
        src: NamedSource::new(
            "cli::main",
            "|fn third() -> FancyResult {
              |   Err(DemoError {
              |       src: NamedSource::new()
              |       })
              |   Ok(())
              |}",
        ),
        bad_bit: (9, 4).into(),
    })?;
    Ok(())
}

When I run this demo, she seems to start working.

Do I need to manually fill in the appropriate code every time and format it for this, the setup is to set some trim flags to match the lock-in. Did I miss something。

This is a binary crate。

[zkat]

If you want to render to a string for comparison, you could consider doing what miette's own test suite does for the graphical reporter: https://github.com/zkat/miette/blob/main/tests/graphical.rs#L29-L32

Is that closer to what you were asking for?

[BppleMan]

If you want to render to a string for comparison, you could consider doing what miette's own test suite does for the graphical reporter: https://github.com/zkat/miette/blob/main/tests/graphical.rs#L29-L32

Is that closer to what you were asking for?

So do I have to hard code my snippet into a NamedSource variable?

like: https://github.com/zkat/miette/blob/main/tests/graphical.rs#L82-L86

[zkat]

no, you don't need to hardcode the source.

[BppleMan]

I mean, if I'm developing an application and also want to get some fancy snippet hints, do I have to hardcode the source. If not, please help direct me where should I go to find the example

[zkat]

You don’t need to hard code the source. You just need to label the field that’s going to be the source with #[source_code] and if you need something more dynamic than that, you can just implement Diagnostic by hand, which is not really that much of a hassle

[BppleMan]

Is there a way to automatically capture context code, the #[source_code]. Sorry this question has been going on for so long. But I've been trying for a while now how to pair anyhow and mitter to automatically capture contextual call stacks and have them output fancy.