You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if a diagnostic pertains to a specific crate (or crates in the case of duplicates), the primary label for it is usually the entry in a synthesized lockfile, which is just the name, version, and source of the crate in question. This isn't really terribly useful, it was mainly done this way due the requirement of codespan_reporting to have a primary label for a "source" span. A better way to display such diagnostics would be to instead follow the dependency links to a root crate(s) in the workspace, and use the line in that crate's cargo manifest that included the crate in question transitively as the primary label, and if additional crates in the workspace at the same level as that root also depend on it, adding those as additional labels. For most projects this will be a more meaningful primary label than the current output.
The text was updated successfully, but these errors were encountered:
Oh, this would also probably include things like using the license expression as it appears in the cargo manifest as well, rather than the synthesized one we use now.
I just noticed that cargo-deny uses codespan! As a heads-up, in the next version we won't require a primary span, so hopefully this makes things easier for you!
Currently, if a diagnostic pertains to a specific crate (or crates in the case of duplicates), the primary label for it is usually the entry in a synthesized lockfile, which is just the name, version, and source of the crate in question. This isn't really terribly useful, it was mainly done this way due the requirement of codespan_reporting to have a primary label for a "source" span. A better way to display such diagnostics would be to instead follow the dependency links to a root crate(s) in the workspace, and use the line in that crate's cargo manifest that included the crate in question transitively as the primary label, and if additional crates in the workspace at the same level as that root also depend on it, adding those as additional labels. For most projects this will be a more meaningful primary label than the current output.
The text was updated successfully, but these errors were encountered: