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

Allow to customize severity of Rules #879

Open
bkolb opened this issue Nov 21, 2024 · 2 comments
Open

Allow to customize severity of Rules #879

bkolb opened this issue Nov 21, 2024 · 2 comments

Comments

@bkolb
Copy link

bkolb commented Nov 21, 2024

At the moment there is no way to way to customize the severity of a rule. There is a TODO already in the code for that, but I cannot find the associated issue.

bkolb added a commit to bkolb/swift-format that referenced this issue Nov 21, 2024
In order to customize the severity of rules, I added
the possibility to do so via the configuration files.
If no severity is specified, we use the one pre-determined
by the Rule itself.

Example:
```
{
    "ruleSeverity": {
        "AlwaysUseLowerCamelCase": "warning",
        "AmbiguousTrailingClosureOverload": "error",
    }
}
```

Issue: swiftlang#879
@ahoppen
Copy link
Member

ahoppen commented Nov 21, 2024

Synced to Apple’s issue tracker as rdar://140346103

bkolb added a commit to bkolb/swift-format that referenced this issue Nov 21, 2024
In order to customize the severity of rules, I added
the possibility to do so via the configuration files.
If no severity is specified, we use the one pre-determined
by the Rule itself.

Example:
```
{
    "ruleSeverity": {
        "AlwaysUseLowerCamelCase": "warning",
        "AmbiguousTrailingClosureOverload": "error",
    }
}
```

Issue: swiftlang#879
@allevato
Copy link
Member

#626 is a related issue; it talks about a different idea (allowing format rules to be configured to turn off the changes they would make but still emit findings), but it also discusses the idea of leveraging that configuration to do things like change the severity.

I'm inclined to leave this issue open though since the severity thing is more of an aside in that issue.

bkolb added a commit to bkolb/swift-format that referenced this issue Nov 22, 2024
In order to check during CI for propper formatting,
it is now also possible to specify severity for
the formating rules.

Issue: swiftlang#879
bkolb added a commit to bkolb/swift-format that referenced this issue Nov 24, 2024
In order to customize the severity of rules, I added
the possibility to do so via the configuration files.
If no severity is specified, we use the one pre-determined
by the Rule itself.

Example:
```
{
    "rules": {
        "AlwaysUseLowerCamelCase": "warning",
        "AmbiguousTrailingClosureOverload": "error",
        "UseLetInEveryBoundCaseVariable": "true", // use rule default
        "UseWhereClausesInForLoops": "false", // disabled
    }
}
```

In addition, one can now control how pretty-print violations
should be treated in the same way

Example:
```
{
    "rules": {
        "TrailingComma": "warning",
        "LineLength": "error",
        "Indentation": "true", // use rule default
        "TrailingWhitespace": "false", // disabled
    }
}
```

Issue: swiftlang#879
bkolb added a commit to bkolb/swift-format that referenced this issue Nov 25, 2024
In order to customize the severity of rules, I added
the possibility to do so via the configuration files.
If no severity is specified, we use the one pre-determined
by the Rule itself.

Example:
```
{
    "rules": {
        "AlwaysUseLowerCamelCase": "warning",
        "AmbiguousTrailingClosureOverload": "error",
        "UseLetInEveryBoundCaseVariable": "true", // use rule default
        "UseWhereClausesInForLoops": "false", // disabled
    }
}
```

In addition, one can now control how pretty-print violations
should be treated in the same way

Example:
```
{
    "rules": {
        "TrailingComma": "warning",
        "LineLength": "error",
        "Indentation": "true", // use rule default
        "TrailingWhitespace": "false", // disabled
    }
}
```

Issue: swiftlang#879
bkolb added a commit to bkolb/swift-format that referenced this issue Nov 25, 2024
In order to customize the severity of rules, I added
the possibility to do so via the configuration files.
If no severity is specified, we use the one pre-determined
by the Rule itself.

Example:
```
{
    "rules": {
        "AlwaysUseLowerCamelCase": "warning",
        "AmbiguousTrailingClosureOverload": "error",
        "UseLetInEveryBoundCaseVariable": "true", // use rule default
        "UseWhereClausesInForLoops": "false", // disabled
    }
}
```

In addition, one can now control how pretty-print violations
should be treated in the same way

Example:
```
{
    "rules": {
        "TrailingComma": "warning",
        "LineLength": "error",
        "Indentation": "true", // use rule default
        "TrailingWhitespace": "false", // disabled
    }
}
```

Issue: swiftlang#879
bkolb added a commit to bkolb/swift-format that referenced this issue Nov 25, 2024
In order to customize the severity of rules, I added
the possibility to do so via the configuration files.
If no severity is specified, we use the one pre-determined
by the Rule itself.

Example:
```
{
    "rules": {
        "AlwaysUseLowerCamelCase": "warning",
        "AmbiguousTrailingClosureOverload": "error",
        "UseLetInEveryBoundCaseVariable": "true", // use rule default
        "UseWhereClausesInForLoops": "false", // disabled
    }
}
```

In addition, one can now control how pretty-print violations
should be treated in the same way

Example:
```
{
    "rules": {
        "TrailingComma": "warning",
        "LineLength": "error",
        "Indentation": "true", // use rule default
        "TrailingWhitespace": "false", // disabled
    }
}
```

Issue: swiftlang#879
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants