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

Jump to bottom

[RFC] Extending the linter interface to allow per-scope settings #436

Closed
whitequark opened this issue Jul 15, 2020 · 3 comments
Closed

[RFC] Extending the linter interface to allow per-scope settings #436

whitequark opened this issue Jul 15, 2020 · 3 comments
Labels
design

Comments

@whitequark
Copy link
Member

Right now nMigen has an extremely simple linter that is also kind of hacky: it lets the first line of a file to contain a # nmigen: magic comment, and this comment allows disabling the UnusedElaboratable warning, mostly to allow creating elaboratables in tests just for their Python interface (i.e. without ever elaborating them). Issues like #404 would benefit from having a more well-defined linter interface.

This interface should allow:

  • enabling/disabling lints in file scope,
  • enabling/disabling lints in a scope delimited by the with statement,
  • avoid issues caused by globals in Python's warnings.catchwarnings.

Although not required, I think that it might be nice to copy Rust's #[allow]/#[warn]/#[deny] system, since it seems to work well for them, and I expect that nMigen users will request a way to make lints into hard errors in the future.
@whitequark whitequark mentioned this issue Jul 15, 2020
Closed
@programmerjake
Copy link
Contributor

seems like a good idea except that it is not the standard Python way.

@programmerjake
Copy link
Contributor

an additional concern is that there should be an API to disable linter features without requiring the python source file of the caller to be accessible, this is needed if using nmigen from some other programming language through CPython's C API.

@jeanthom jeanthom mentioned this issue Jul 28, 2020
Closed
@whitequark whitequark added design and removed feature labels Jul 31, 2020
@whitequark
Copy link
Member Author

While in principle still feasible, the direct motivation for this feature is gone now that #1059 obviates the need for configuring that particular warning.

I am going to close this issue now. This isn't to imply rejection of the proposal, but simply an indication that it should go through our new RFC process now (described at https://amaranth-lang.org/rfcs/).

@whitequark whitequark closed this as not planned Won't fix, can't repro, duplicate, stale Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
design
Milestone
No milestone
Development

No branches or pull requests
2 participants
@whitequark @programmerjake