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

Emit advice that compiles #8770

Merged
merged 1 commit into from Mar 1, 2020
Merged

Emit advice that compiles #8770

merged 1 commit into from Mar 1, 2020

Conversation

hrhino
Copy link
Member

@hrhino hrhino commented Feb 29, 2020

Like it asks for on the ticket. Presumably there's a lot more advice that doesn't compile, such as scala/bug#11301, but here's a step forward.

Fixes scala/bug#9908.

@scala-jenkins scala-jenkins added this to the 2.12.12 milestone Feb 29, 2020
@@ -61,8 +61,8 @@ it has 13 unimplemented members.

class Baz[T] extends Collection[T]
^
abstract-report2.scala:15: error: class Dingus needs to be abstract, since:
it has 24 unimplemented members.
abstract-report2.scala:21: error: class Dingus needs to be abstract, since:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OT/apropos of nothing, I noticed the since: is weird because of deprecation messaging.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it is. Also, why the newline?

// Members declared in Symbolic
def --!(i: Int): Unit = ???
def --? : Int = ???
def unary_~ : Long = ???
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noice.

@hrhino
Copy link
Member Author

hrhino commented Feb 29, 2020

I was hoping @som-snytt was going to approve without waiting for the build, but he's shrewder than that.

 Object {
   final private val x: Int
   def x(): Int
-  def <init>(): Object{def x(): Int}
+  def <init>(): $anon$1
 }

@som-snytt
Copy link
Contributor

som-snytt commented Feb 29, 2020

@hrhino A task came up on my day job, I'll get back to it in a bit.

I did single comments so you wouldn't have to wait for the actual review.

)
else if (isModule) "" // avoid "object X of type X.type"
else tp match {
case PolyType(tparams, res) => typeParamsString(tp) + loop(res)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My last thought before the vp asked me to look at something was that this will trigger -Xlint:recurse-with-default when merged forward.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I making life interesting for @SethTisue or whoever does the forward merges, or am I just being irritating? AFAIR we don't use that flag so maybe it's a pending enhancement for your next tranche of warnings fixups.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the flag you approved in January on 2.13.

else tp.resultType match {
case rt @ TypeBounds(_, _) => "" + rt
case rt => " <: " + rt
def loop(tp: Type, first: Boolean = false): String = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You know what's clever? Shadowing an outer param in an inner loop, so it looks like the whole thing only has one param.

You know what's wrong?

@som-snytt
Copy link
Contributor

@som-snytt
Copy link
Contributor

Oh good, it passed. Let me know if you like the version with aligned arrows. I also renamed the boolean. Otherwise LGTM.

Copy link
Contributor

@som-snytt som-snytt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wins for most work to insert a space.

@dwijnand
Copy link
Member

Let me know if you like the version with aligned arrows.

Yeah, what's up with that? You care about whitespaces, but then you don't? Signed, a-vertical-alignment-lover.

@som-snytt
Copy link
Contributor

The urban dictionary definition of vertical alignment lover is when you find someone your own height. It probably means something else, too.

@hrhino hrhino force-pushed the t9908 branch 3 times, most recently from 4cf3f02 to a8f7289 Compare March 1, 2020 00:23
Like it asks for on the ticket. Presumably there's a lot more advice
that doesn't compile, such as scala/bug#11301, but here's a step forward.

Fixes scala/bug#9908.

Tweaked, reformatted, and generally

Co-Authored-By: "Som Snytt" <som.snytt@gmail.com>
@hrhino
Copy link
Member Author

hrhino commented Mar 1, 2020

@som-snytt I did like it, thanks. I hope you don't mind me squashing your commit. I gave you Co-Authored-By credit, as if anyone looks that closely.

@dwijnand I too am a vertical-alignment lover! (And also a compound-adjective hyphenator.) IntelliJ, on the other hand, drops those spaces whenever I ask it to do something as simple as indent a new block. Please forgive me.

@hrhino
Copy link
Member Author

hrhino commented Mar 1, 2020

#8776 by way of penance.

@som-snytt
Copy link
Contributor

Very impressive crediting, I expected just a quick cut/paste. I only started editing because I was stuck at the office and mistakenly thought the commit wasn't passing.

@som-snytt som-snytt merged commit ed743e5 into scala:2.12.x Mar 1, 2020
@som-snytt
Copy link
Contributor

@SethTisue Wondering how many 2.12 contributions will be orphaned by the current milestone?

@hrhino
Copy link
Member Author

hrhino commented Mar 1, 2020

You can be the release lead for 2.12.11-and-3/4.

@lrytz lrytz modified the milestones: 2.12.12, 2.12.11 Mar 2, 2020
@SethTisue
Copy link
Member

SethTisue commented Mar 2, 2020

Wondering how many 2.12 contributions will be orphaned by the current milestone?

Unfortunately we don't have tooling for using a release branch to keep 2.12.11 and 2.12.12 work separate.

So, let's all please exercise a higher-than-usual level of caution about merging 2.12.x PRs until 2.12.11 is out the door, and even for a little while afterwards, in case we end up needing to rush a followup.

In any case, this one seems safe. Such a small word, "seems" :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants