-
Notifications
You must be signed in to change notification settings - Fork 178
Unused cases in a switch do not trigger warnings #404
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
Comments
Resolves amaranth-lang#404 Signed-off-by: Filipe Laíns <lains@archlinux.org>
I've submitted a PR. To enabling filtering out the warning I propose declaring a new warning type, which could then be ignored. |
Sorry but any attempt to fix this issue (or any other issue that touches language features) is premature until we actually agree on the design. I prefer to have no fix at all to a careless fix that negatively impacts downstream.
I don't like the solution of explicitly disabling lints by name. Sometimes it's unavoidable, sure, like in case of |
We had a discussion about this issue on IRC: https://freenode.irclog.whitequark.org/nmigen/2020-06-16#1592311000-1592313032; Long story short, the issue goes much further than just checking the position of the default case. We should actually check for unreachable cases in a switch (which covers the default case being in first position, but also other scenarios), but we shouldn't forget that in some applications (eg. generated code) those checks are unneeded and for those situations we should let the user disable those warnings. |
The purpose was mainly to get something started.
I am not sure if I parse this correctly. Warnings are very easy to suppress, actually more than anything you could ever do programmatically. But you can build something directly, or on top of the warnings module, it does not make much difference here. The benefits of using the warnings module is that we would not have to care about the warning suppression in the code that is issuing them. Anyway, there is no need for me to try being a perfectionist and force you to spend some of your time arguing about the technicalities of the implementation, so I will not pick this battle. Can you describe the mechanism you had in mind? Or do you prefer to implement it yourself? |
The life of a language feature does not start with code.
The specific mechanism for disabling the warnings for unreachable cases, or the general approach? The general approach can be seen in
There can be no implementation until there is a design! Which is what this issue is about. |
The mechanism to disable the warnings.
I was thinking we could just do it when exiting the context manager. This is what makes the most sense to me. |
Ah sorry, I was unclear earlier. I meant that I don't know yet what kind of user-visible mechanism there should be to disable the warnings for unreachable cases, and that we should discuss that. It doesn't really matter at this point how the logic of emitting the warnings should be implemented—in general until the design is done I don't care at all about the implementation in cases where it's clear that some reasonable implementation is possible. |
Okay, what do you want to do? I proposed declaring a new warning type which could then be filtered. We can declare a warning type for these cases and then subclass the specific warnings from there. Warnings are easily filterable, but we can even provide a helper function to do just that if you want. This is what I was proposing above, I am not sure if it was clear enough. You didn't seem to be a fan of my approach. |
Just a note. I am not knowledgable enough in the code structure to propose a direct way to do this in the code, so you'll have to be the one providing an option. |
I'm not expecting you to propose any way to do this in the code! Implementation is secondary to the interface; until we decided on the interface it doesn't even make sense to talk about the implementation for the most part. Anyway, let's see which options we have for the interface used to suppres the warning:
Both (2) and (3) seem generally alright, with a weak preference for (3). If we go with (2) this issue is easy to fix; (3) will need further design work to figure out how linter options should be configured. |
Of course there can be other possible strategies that I'm missing, so anyone reading these comments is welcome to suggest alternatives. |
I have a preference towards 3). Can you point me to the linter code? |
Sure, search for |
I've filed an RFC #436 to discuss this. |
Looking over this again, there is basically no reason to ever have cases after Sorry @FFY00, I think I wasn't feeling very well when first looking at the issue and didn't approach it in the most constructive way. I'll add this functionality taking your PR as a base. |
Discussed on the 2023-02-06 weekly meeting, with no conclusion reached beyond no one objecting to catching common cases of this issue without a full exhaustiveness check. In my view, there are three intersecting issues at play here:
Even if we implement (1) we still should do something about (2) since an exhaustiveness check will say nothing about an The key difficulty here is the lack of a linter interface, which I don't think will get better any time soon. So I'm focusing on solutions that avoid it. One such solution is always emitting a warning for a literal |
Now that |
Consider those two elaboratables:
Because the default/wildcard case was declared first in Impl1, it prevents Case(0) and Case(1) from being matched. This is a bit misleading for newbies who would expect cases to be position agnostic (and therefore Impl1 having equivalent behaviour as Impl2).
As discussed on IRC, a sensible way of dealing with that issue would be to trigger warnings whenever some cases are unreachable. We still have to figure out how we can silence those warnings when they are undesired (think code generation).
The text was updated successfully, but these errors were encountered: