Bump https://github.com/atelico/gdstyle from v0.2.5 to 0.3.0

[dependabot]

Bumps https://github.com/atelico/gdstyle from v0.2.5 to 0.3.0.

Release notes

Sourced from https://github.com/atelico/gdstyle's releases.

v0.3.0

gdstyle 0.3.0

Per-rule "error" severity never actually worked. It parsed, and was then thrown away, so every diagnostic printed as a warning and gdstyle check always exited 0. If you set rules to "error" expecting CI to fail on them, it never did. This release fixes that and closes the two gaps that made it hard to notice, plus adds a way to fail a build on warnings without escalating rules one at a time.

Fixed

• "error" severity in [rules] is now applied to diagnostics. Config::rules is three-valued ("off", "warn", "error"), but the only code reading it collapsed that to a boolean, "is this rule on?". The "warn" versus "error" distinction was parsed and discarded, so every rule emitted a warning. Because check exits 1 only when it sees an error-severity diagnostic, no configuration could fail a build:

  [rules]
  "naming/variable-name-snake-case" = "error"
  "naming/function-name-snake-case" = "error"

  # 0.2.5
  3:1 warning variable name 'BadName' should use snake_case ...
  5:1 warning function name 'DoThing' should use snake_case ...
  1 file checked, 2 warnings found.        $? = 0
  0.3.0
  3:1 error variable name 'BadName' should use snake_case ...
  5:1 error function name 'DoThing' should use snake_case ...
  1 file checked, 2 errors found.          $? = 1
  

  Severity is now applied in lint_source, the single entry point the CLI, the GDExtension and the formatter all share, so the CLI, --format json and the Godot editor panel agree. A rule you say nothing about keeps its own default, which leaves syntax/lex-error an error while still letting an explicit "warn" downgrade it.

  Reported in #29, with a complete reproduction that is now pinned as a regression fixture.

Added

• Unknown rule names in [rules] are reported instead of ignored. A misspelled key is valid TOML and used to be dropped on the floor, so a

... (truncated)

Changelog

Sourced from https://github.com/atelico/gdstyle's changelog.

gdstyle 0.3.0

Per-rule "error" severity never actually worked. It parsed, and was then thrown away, so every diagnostic printed as a warning and gdstyle check always exited 0. If you set rules to "error" expecting CI to fail on them, it never did. This release fixes that and closes the two gaps that made it hard to notice, plus adds a way to fail a build on warnings without escalating rules one at a time.

Fixed

• "error" severity in [rules] is now applied to diagnostics. Config::rules is three-valued ("off", "warn", "error"), but the only code reading it collapsed that to a boolean, "is this rule on?". The "warn" versus "error" distinction was parsed and discarded, so every rule emitted a warning. Because check exits 1 only when it sees an error-severity diagnostic, no configuration could fail a build:

  [rules]
  "naming/variable-name-snake-case" = "error"
  "naming/function-name-snake-case" = "error"

  # 0.2.5
  3:1 warning variable name 'BadName' should use snake_case ...
  5:1 warning function name 'DoThing' should use snake_case ...
  1 file checked, 2 warnings found.        $? = 0
  0.3.0
  3:1 error variable name 'BadName' should use snake_case ...
  5:1 error function name 'DoThing' should use snake_case ...
  1 file checked, 2 errors found.          $? = 1
  

  Severity is now applied in lint_source, the single entry point the CLI, the GDExtension and the formatter all share, so the CLI, --format json and the Godot editor panel agree. A rule you say nothing about keeps its own default, which leaves syntax/lex-error an error while still letting an explicit "warn" downgrade it.

  Reported in #29, with a complete reproduction that is now pinned as a regression fixture.

Added

• Unknown rule names in [rules] are reported instead of ignored. A misspelled key is valid TOML and used to be dropped on the floor, so a config looked like it had taken effect when it silently did nothing. This

... (truncated)

Commits

• c104357 chore(release): 0.3.0
• b2202b6 feat(config): honor per-rule severity and report unknown rule names (#30)
• 5efccc9 ci(release): verify the crates.io token before publishing anything
• 965b9f3 docs: refresh README and 0.2.5 release notes
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)