-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Warn about unintended underscores #8699
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
Conversation
|
The other possible feature is to elide the temporary, which is unused. That also sounds like a good first issue. The flags tests in Typers deserve more scrutiny; it may not matter, since finding the attachment is definitive. Github doesn't suggest a reviewer, knowing that no one will want a piece of this. |
831338b to
ea0c2d3
Compare
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 is very helpful! I agree that mentioning locally in the warning is a good idea.
If a pattern definition binds no variables, it is probably a mistake if it is marked implicit, because it introduces no implicit values, or if it is a template statement, because it accidentally introduces a template member. Also since the Scouts are selling cookies this week, I did some Girl Scouting and tweaked doc for partest and improved some tests, including a test that fails under Java 9 because it uses underscore.
ea0c2d3 to
31a4008
Compare
|
The latest includes |
|
/rebuild (to check if jenkins is back) |
|
Bonus follow-up could be to warn about spurious tuple fields resulting from pattern deconstruction $> cat A.scala
case class C(x: Int, y: Int)
class A {
val C(a, b) = C(1, 2)
val (c, d) = (1, 2)
}$> cfr-decompiler A.class
public class A {
private final /* synthetic */ Tuple2 x$1;
private final int a;
private final int b;
private final /* synthetic */ Tuple2 x$2;
private final int c;
private final int d;
public int a() {
return this.a;
}
public int b() {
return this.b;
}
public int c() {
return this.c;
}
public int d() {
return this.d;
}
public A() {
C c = new C(1, 2);
if (c == null) {
throw new MatchError((Object)c);
}
int a = c.x();
int b = c.y();
Tuple2.mcII.sp sp2 = new Tuple2.mcII.sp(a, b);
this.x$1 = sp2;
this.a = this.x$1._1$mcI$sp();
this.b = this.x$1._2$mcI$sp();
Tuple2.mcII.sp sp3 = new Tuple2.mcII.sp(1, 2);
if (sp3 == null) {
throw new MatchError((Object)sp3);
}
int c2 = sp3._1$mcI$sp();
int d = sp3._2$mcI$sp();
Tuple2.mcII.sp sp4 = new Tuple2.mcII.sp(c2, d);
this.x$2 = sp4;
this.c = this.x$2._1$mcI$sp();
this.d = this.x$2._2$mcI$sp();
}
} |
|
Thanks. Scala progresses because of brave individuals who merge stuff. |
|
Doti will have a warning about unindented underscores. |
|
@som-snytt how come I don't get the warning in the first case? |
|
I can't believe no one laughed at "unindented underscores." I was sick that week, answering the question what was I doing on Valentine's, a couple of days later I was two solid days and nights laid out in bed, for some reason not permanently. @SethTisue guessing scala/bug#11957 |
|
This change just helped me find and delete a line of dead code. Thanks @som-snytt! |
If a pattern definition binds no variables, it is
probably a mistake if it is marked implicit,
because it introduces no implicit values,
or if it is a template statement, because
it accidentally introduces a template member.
Fixes scala/bug#11618