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
Pattern match induces "will most likely never compare equal" #747
Comments
When I check out your commit and remove (revert) the nowarn from Shrinkable, I don't see a ("does not suppress") warning there, but I do see the warning on Growable:
That is both straight and bootstrapped. Is it possible it never warned on the current edit of subtractAll?
contrast
By contrast, the following message does disappear on bootstrap, which demonstrates that the warning was newly introduced:
|
I don't recall any PR that aimed to add any smarts like that. I think the next investigation step here would be to bisect, using published nightlies, to identify the PR where the behavior changed. At that point it should be obvious whether it's a progression or regression. |
My previous comment was that reverting the nowarn at the time it was committed does not induce a warning, but leaving it in does induce the "suppresses nothing". I verified that no 2.13 release warns on the comparison, which has the form:
I don't if there was a warning between releases. I don't think you can bisect if the behavior never changed. |
I believe the PR ended up getting rebased several times, so it's possible that the commit that ended up getting merged didn't need them. however, the annotations were definitely needed by the original commit (this actually preceded fatal warnings in the library module) |
@som-snytt see NthPortal/scala@b5c8443 (the original commit introducing the annotations) and NthPortal/scala@04a311e (a commit I just made removing the annotations, that warns). parent commit on scala/scala is scala/scala@7b85389 |
I get the same result building what you say is the parent commit. Oh wait, now I see what you saw. The line it warns on from your repo is different from what I cited in scala/scala:
Cf https://github.com/scala/scala/blame/2.13.x/src/library/scala/collection/mutable/Growable.scala#L61 I don't actually know what the type is in the pattern guard. Presumably I would also cite this as a reason I don't like the "shadow a name as more precise type in pattern match" because it is in fact hard to read. In short, you never committed the code that warns. |
huh, interesting. I actually changed the code as per Jason's request (scala/scala#9174 (comment)), so... 🤷♀️ I guess we can get rid of the annotations and leave it at that then |
thanks for catching that @som-snytt |
It warns in 2.13.0:
where that is a refinement. Some previous refinement tweaking touched the (dubious) refcheck in 2.12.7. Maybe something related was retweaked for 2.13.0. |
Extraneous nowarn deleted at scala/scala#9442 which incurred some serious déjà vu. |
I'm not sure there's actually a bug here. I think the warning on a pattern match is correct, as the compiler has no way of knowing the types are related (since |
The warning tries to be conservative and not noisy. It's supposed to emit some advice only when it has something useful to say, like Mr Ed the talking horse. So I would say definitely undesired behavior; but I'm not sure the feature is worth investing much time in. |
There is a case in
s.c.m.Shrinkable
and a case ins.c.m.Growable
where we check if a{Growable|Shrinkable}
iseq
to anIterableOnce
. As they do not share any type belowAny
, the compiler previously warned that they would "most likely never compare equal", and we added a@nowarn
annotation because the compiler is wrong (mutableSet
s,Map
s andBuffer
s all extendIterableOnce
,Shrinkable
andGrowable
).At some point the compiler stopped warning for these cases, which came up at scala/scala#9301 (comment) when Seth was doing some cleanup.
Are the missing warnings a regression, or the compiler getting smarter somehow (does it track all types inheriting from both of them?)?
The text was updated successfully, but these errors were encountered: