-
Notifications
You must be signed in to change notification settings - Fork 198
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
add more scalac 2.12 warnings #6798
Conversation
CHANGELOG_BEGIN CHANGELOG_END
package.scala:18: warning: it is not recommended to define classes/objects inside of package objects. If possible, define trait NoCopy in package data instead. trait NoCopy { ^
- note that `package` is itself a scoping construct, so if your reason is the apparent aesthetic of placing a bunch of things in one `package object`, that is easily remedied by deleting the `object` keyword
- I'm generally in favor of sensible name-shadowing, following the "deliberately hide variables that should not be accessed here" school of thought. But I think type name shadowing isn't quite as valuable and more likely to confuse than general variable shadowing, so have experimentally linted it out. Example warning: EventsTableFlatEventsRangeQueries.scala:11: warning: type parameter Offset defined in trait EventsTableFlatEventsRangeQueries shadows class Offset defined in package v1. You may want to rename your type parameter, or possibly remove it. private[events] sealed trait EventsTableFlatEventsRangeQueries[Offset] { ^
ContractsService.scala:197: warning: method searchDb in class ContractsService references private class ContractsFetch. Classes which cannot access ContractsFetch may be unable to override searchDb. def searchDb(dao: dbbackend.ContractDao, fetch: ContractsFetch)( ^
@@ -49,6 +49,16 @@ common_scalacopts = [ | |||
"-Xfatal-warnings", | |||
# catch missing string interpolators | |||
"-Xlint:missing-interpolator", | |||
"-Xlint:by-name-right-associative", # will never be by-name if used correctly |
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 fixed by scala/scala#5969 for 2.13, so we can remove it if we're 2.13 only.
…lac-2.12-warnings
Commentary on lints not enabled by this PR.
Already disabled by
Already enabled for
I never thought these options were very useful when they were under
I'd rather not enable a warning "just 'cause".
This disables a bunch of useful matches like the following; no thanks. PackageManagementServiceIT.scala:53: warning: A repeated case parameter or extracted sequence is not matched by a sequence wildcard (_*), and may fail at runtime.
case Participants(Participant(ledger, party)) =>
^ |
bazel_tools/scala.bzl
Outdated
"-Xlint:constant", # / 0 | ||
"-Xlint:doc-detached", # floating Scaladoc comment | ||
"-Xlint:inaccessible", # method uses invisible types | ||
"-Xlint:infer-any", # less through but less buggy version of the Any wart |
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.
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.
Looks nice.
package inner { | ||
case class FieldInfo(damlName: String, damlType: Type, javaName: String, javaType: TypeName) | ||
} | ||
|
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.
@S11001001
what exactly does it buy us? Before this change all definitions were inside package object inner
, now we have package inner
.
why public type alieas type Fields = IndexedSeq[FieldInfo]
is not part of the package inner
?
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.
what exactly does it buy us?
A class or object in a package object must be accessed by reference to that package object. If it is in a package, you can access it directly. This difference is mostly transparent to Scala code, but not to the JVM, or Java code (where that matters).
Additionally, because package objects have been historically buggy, it is best to minimize what you put in them.
why public type alieas
type Fields = IndexedSeq[FieldInfo]
is not part of thepackage inner
?
This is not allowed.
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.
By the way, in Scala, the Java-style package
declaration[s] at top of file are just syntactic sugar for the full package x { ... }
form; the { }
are implicitly placed around the rest of the file. That's what I mean by "package
is itself a scoping construct" 🙂
navigator/backend/src/main/scala/com/digitalasset/navigator/console/package.scala
Show resolved
Hide resolved
type NameMatcher = String => Boolean | ||
type ValueMatcher = String => Boolean | ||
type Action[T, R, C] = (T, PropertyCursor, String, C) => Either[DotNotFailure, R] | ||
|
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.
does it mean you cannot have type aliases defined in the non-object package?
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.
Indeed. 🙂
- there are a lot of these fixes, and they are noisy, so shifting to a separate PR - thanks to @leo-da for pointing out
Split |
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.
Thanks!
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.
Looks good to me.
@@ -49,6 +51,16 @@ common_scalacopts = [ | |||
"-Xfatal-warnings", | |||
# catch missing string interpolators | |||
"-Xlint:missing-interpolator", | |||
"-Xlint:by-name-right-associative", # will never be by-name if used correctly | |||
"-Xlint:constant", # / 0 |
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.
What does "/ 0" mean?
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.
Divide by 0.
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.
I had guessed that much. It doesn't tell me what the linting rule does though. 😛
After reading the definition of -Xlint:constant
, I guess this catches cases where we divide by 0
that only use constants? Still not sure though.
Sometimes codifying guidelines that have already come up in code review, sometimes checking probably-wrong constructs. I chose the lints to add based on tpolecat's 2.12 list, picking the ones that either I was familiar with or sounded good, leaving out a couple. Examples fixed here:
Note that
package
is itself a scoping construct, so if your reason is the apparent aesthetic of placing a bunch of things in onepackage object
, that is easily remedied by simply deleting theobject
keyword, such as I do in c5e8c3b.This should be especially useful given modularization efforts such as @rautenrieth-da 's in #6695 and other PRs.
I noticed this in #6658. I'm generally in favor of sensible name-shadowing, following the "deliberately hide variables that should not be accessed here" school of thought. But I think type name shadowing isn't quite as valuable and more likely to confuse than general variable shadowing, so have experimentally linted it out; see dad17ec for the results. We can easily revert that part of this PR if we don't like the rule, though.
Pull Request Checklist
CHANGELOG_BEGIN
andCHANGELOG_END
tagsNOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with
/AzurePipelines run
totrigger the build.