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

Enable -Werror for more modules #9304

Merged
merged 3 commits into from Nov 23, 2020
Merged

Conversation

NthPortal
Copy link
Contributor

No description provided.

@NthPortal NthPortal added the internal not resulting in user-visible changes (build changes, tests, internal cleanups) label Nov 6, 2020
@scala-jenkins scala-jenkins added this to the 2.13.5 milestone Nov 6, 2020
@NthPortal
Copy link
Contributor Author

I may add commits for more modules if I have the capacity - we'll see

@@ -349,6 +350,7 @@ class Settings(error: String => Unit, val printMsg: String => Unit = println(_),
/** Dirty, dirty, dirty hack: the value params conversions can all kick in -- and they are disambiguated by priority
* but showing priority in scaladoc would make no sense -- so we have to manually remove the conversions that we
* know will never get a chance to kick in. Anyway, DIRTY DIRTY DIRTY! */
@nowarn("cat=lint-nonlocal-return")
Copy link
Contributor

Choose a reason for hiding this comment

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

Could also use @nowarn("cat=dirty-dirty-dirty")

@SethTisue
Copy link
Member

@NthPortal maybe rebase and finish off what you have here, and leave possible future work on other modules for a separate PR?

@SethTisue
Copy link
Member

and, note that if you worked on a module and got rid of some warnings but didn't get it to where -Werror can be enabled, that work is still mergeable

@NthPortal
Copy link
Contributor Author

@SethTisue all the warnings were gone when I wrote the commits; it seems like other warnings crept in since then. I'll... see if i can clean it up again

@SethTisue
Copy link
Member

SethTisue commented Nov 22, 2020

yeah this is an area where the forces of entropy work swiftly

now that 2.13.4 is out and is apparently not catastrophically flawed, the team has more bandwidth again to help you make sure this lands. (if you find yourself without time to work on it, let us know and one of us can finish it.)

Tweak -Wconf options to conform to the help text.

Use `@unchecked` instead of `@nowarn` for exhaustiveness warnings.
Enable linting for scalap build and fix all deprecations
in the module.

Enable -Werror for scalap build.
Enable linting for scaladoc build and fix or suppress all
deprecation, linting and feature warnings in the module.

Enable -Werror for scaladoc build.

/** The end of a Scaladoc code block */
private val CodeBlockEndRegex =
new Regex("""(.*?)((?:\}\}\})|(?:\u000E</pre>\u000E))(.*)""")
new Regex("""(.*?)((?:\}\}\})|(?:</pre>))(.*)""")
Copy link
Member

Choose a reason for hiding this comment

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

What's this change about? (Have I asked this already?)

Copy link
Contributor Author

@NthPortal NthPortal Nov 23, 2020

Choose a reason for hiding this comment

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

I replaced it with the literal \u000E character, which looks like (rendering varies). for some reason, github isn't rendering it in diff mode, but if you look at the full file without diff, it's there:

new Regex("""(.*?)((?:\{\{\{)|(?:�<pre(?: [^>]*)?>�))(.*)""")
/** The end of a Scaladoc code block */
private val CodeBlockEndRegex =
new Regex("""(.*?)((?:\}\}\})|(?:�</pre>�))(.*)""")

Copy link
Member

Choose a reason for hiding this comment

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

I see, thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

Is this because we don't know how "\u" is processed any more? There's also "\x0e".

raw"\x09".r.findAllMatchIn("aaa\tbbb\tccc").map(_.start).toList

Copy link
Member

Choose a reason for hiding this comment

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

I fear that GitHub isn't the only tooling that isn't going to handle an embedded invisible control character well. I think it would really be better to use an escape. No opinion on \x vs \u, but note that since #8282 , \u is no longer weird/special

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the reason I replaced it was because of a warning that said to use a literal; I have no particular opinion on it otherwise

Copy link
Contributor

Choose a reason for hiding this comment

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

I tried it and it is awkward. It's stuck half-way, like Winnie-the-Pooh. I'd recommend \x. I'm going to try \X; there's that other PR about mkstring with unicode points.

scala> "a\u0009b"
val res0: String = a    b

scala> raw"a\u0009b"
            ^
       warning: Unicode escapes in raw interpolations are deprecated. Use literal characters instead.
val res1: String = a    b

Copy link
Member

@SethTisue SethTisue Dec 4, 2020

Choose a reason for hiding this comment

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

what on earth is this random control character doing in the regexes in the first place? surely Scaladoc doesn't actually use control-N for anything.... one hopes? is it possible somebody meant control-M, which is carriage return? control-N is "SO (SHIFT OUT)", does anybody under the age of 80 even know what that is?

Copy link
Member

Choose a reason for hiding this comment

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

let's see if all the tests still pass if we just take it out: #9359

Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

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

Basically good to go, IMO. Just one question above a regex change(?)

@dwijnand dwijnand merged commit 867f63a into scala:2.13.x Nov 23, 2020
@NthPortal NthPortal deleted the topic/werror-4/PR branch November 23, 2020 18:07
@SethTisue
Copy link
Member

I propose a special 🎖️ for "dedication to clean code,"

indeed, 🎖️ to @NthPortal for taking this on, this kind of work has a lasting positive impact on the health of the codebase

SethTisue added a commit to SethTisue/scala that referenced this pull request Dec 4, 2020
surely they can't actually mean anything or be doing anything?
(surely?)

this came up on scala#9304
SethTisue added a commit to SethTisue/scala that referenced this pull request Dec 4, 2020
I have no idea why we need these control-N characters in
these regexes, but it's better not to embed them literally,
and Unicode escapes inside triple quotes are deprecated

this came up on scala#9304
SethTisue added a commit to SethTisue/scala that referenced this pull request Dec 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal not resulting in user-visible changes (build changes, tests, internal cleanups)
Projects
None yet
5 participants