-
Notifications
You must be signed in to change notification settings - Fork 107
refactor: config codegen #598
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
base: main
Are you sure you want to change the base?
Conversation
| use crate::{Rules, linter::RuleGroup}; | ||
|
|
||
| #[derive(Clone, Copy, Debug, Eq, PartialEq, Hash)] | ||
| pub enum RuleSelector { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will be made more generic in a future pr
- Fix unresolved import from analyser to linter in workspace tests - Remove empty line after outer attribute in diagnostics - Apply clippy suggestions for cleaner code 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
- Add ORDER BY clause to roles query for deterministic results - Update role completion tests to expect all default Supabase roles - Create helper function to centralize expected roles list - Update SQLx offline cache for modified query 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
juleswritescode
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
The way I understand it is: "rules" are an abstraction layer over lints, actions, transformations.
Then the "lints" will come from many tools: splinter, pglinter, and so on.
What's still throwing me off a bit is that our lint rules (mostly squawk, eugene, typecheck?) are called "linter" right now. Maybe we can somehow make it more clear that linter is one of many linters by naming it "internal" or something?
The idea is that "rules" are the abstraction for not only lints, actions and transformations, but also for diagnostics emitted from other tools such as splinter. and the linter is the "source code rules engine", and it emits "normal" lints. we will then add another crate for assists and transformations if we need them. The other tools (eg splinter) are also declaring "rules" and emit diagnostics for rules, but are not declared as "linter". But I agree that it's not 100% perfect. Open to suggestions, but I have troubles finding a name for the "source code linter" that is not "linter". |
rewires the pgls_configuration crate alongside its codegen xtask as a preparation for new lint tools (
splinterandpglinter). its all the same as before, I just moved things in the config crate around, and the xtask is geared towards tools vs just the analyser. common primitives are now in/rules/, and we generate one dir per tool (linter,splinter,pglinter) etc.the codegen refactoring was initially written by me but completed by Claude. Everything outside of xtask/ was done by hand or is re-generated.
TODO (in follow-up prs)
pgls_analysercrate topgls_linterpgls_pglinter,pgls_splinterandpgls_assistsand integrate them withpgls_analyseto allow aRuleVisitorto collect the metadataAnalysera bit.