-
Notifications
You must be signed in to change notification settings - Fork 85
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
Line numbers in error/warning messages when referring to deny.toml are wrong #264
Comments
This is a limitation with how we get span information when parsing the toml configuration files, which is essentially just a copy of what the I think fixing this would be very valuable, since I'm now remembering this is the same issue for why we cheat and generate some toml when displaying the spans for where a value came from in a Cargo.toml manifest, but I might not be able to get to it for a while. |
Related: #136 |
Helps with (but doesn't fix) EmbarkStudios#264
Helps with (but doesn't fix) EmbarkStudios#264
Helps with (but doesn't fix) #264
This PR completely refactors the deny configuration, notably: ### `toml-span` `toml-span` is now used for parsing toml files (currently only deny.toml, but eventually cargo manifests as well), replacing `toml`. This was done so that span information is _always_ available for keys and values if we want to use it, as well as just reducing external dependencies and build times, as serde is no longer used. ### `PackageSpec` Specifying a package spec via the name + version combo occurs in many locations in the config, but this has verbose in both the simple case, where you just want to specify a crate name (eg. `[bans.deny]`), as well as needing an entire extra key if you _do_ want to specify the version requirement. In addition, it was not possible to specify just a string previously due to toml + serde making us decide between supporting plain strings for package specs, and span information. In all cases (and a few new ones) where the package name + version could be used, now a simple string can be used instead, or, if you want/need to supply additional values as a table, the `crate` key can be used instead which follows a simple format as a single string, instead of the separate name/version keys. `name` and `version` are still supported, but are deprecated and will be removed in a future release. #### Format The string format of `PackageSpec` is quite simple: 1. No version - `<crate_name>` = `*` 1. Exact - `<crate_name>@<semver>` = `=<semver>` 2. Requirements - `<crate_name>:<semver_requirements>` = `<semver_requirements>` ### Add `reason`, `use-instead` Many items can now be tagged with a `reason = "<reason>"` and/or `use-instead = "<crate_name>/<url>"` to add explanatory/helpful messages that are surfaced with diagnostic messages. This was added to fix #578 instead of the typical fallback of relying on toml comments that might not be part of the diagnostic span. ### `[advisories.ignore]` Yanked crates can now be ignored by specifying a crate spec + optional reason as a string or table, while still supporting advisory ids. ### Root table improved The `targets`, `all-features`, `features`, `no-default-features`, `exclude`, and `exclude-dev` keys have been moved to the new `graph` table, as they all affect the dependency graph that cargo-deny performs checks against. The `feature-depth` key has been moved to the `output` table. The old locations are still respected, but are deprecated. Note also that `targets` can now just take a string instead of `triple = <target_triple>`. Resolves: #264 Resolves: #539 Resolves: #578 Resolves: #579
This for example is a
[[bans.skip]]
around line 30 and nothing around line 1.The text was updated successfully, but these errors were encountered: