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

add more scalac 2.12 warnings #6798

Merged
merged 12 commits into from
Jul 21, 2020
Merged

add more scalac 2.12 warnings #6798

merged 12 commits into from
Jul 21, 2020

Conversation

S11001001
Copy link
Contributor

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:

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 simply deleting the object keyword, such as I do in c5e8c3b.

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)(
      ^

This should be especially useful given modularization efforts such as @rautenrieth-da 's in #6695 and other PRs.

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] {
                                                               ^

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

  • Read and understand the contribution guidelines
  • Include appropriate tests
  • Set a descriptive title and thorough description
  • Add a reference to the issue this PR will solve, if appropriate
  • Include changelog additions in one or more commit message bodies between the CHANGELOG_BEGIN and CHANGELOG_END tags
  • Normal production system change, include purpose of change in description

NOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with /AzurePipelines run to
trigger the build.

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
Copy link
Contributor Author

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.

@S11001001
Copy link
Contributor Author

Commentary on lints not enabled by this PR.

  adapted-args               Warn if an argument list is modified to match the receiver.

Already disabled by -Yno-adapted-args.

  unused                     Enable -Ywarn-unused:imports,privates,locals,implicits.

Already enabled for lf_scalacopts; if you like, we can move it in a separate PR.

  nullary-unit               Warn when nullary methods return Unit.
  nullary-override           Warn when non-nullary `def f()' overrides nullary `def f'.

I never thought these options were very useful when they were under -Ywarn-, no reason to think differently now.

  delayedinit-select         Selecting member of DelayedInit.

I'd rather not enable a warning "just 'cause".

  stars-align                Pattern sequence wildcard must align with sequence component.

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)) =>
                      ^

"-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
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Continuing the saga of #6116 and #6132.

Copy link
Collaborator

@remyhaemmerle-da remyhaemmerle-da left a comment

Choose a reason for hiding this comment

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

Looks nice.

Comment on lines +18 to +21
package inner {
case class FieldInfo(damlName: String, damlType: Type, javaName: String, javaType: TypeName)
}

Copy link
Contributor

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?

Copy link
Contributor Author

@S11001001 S11001001 Jul 20, 2020

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 the package inner?

This is not allowed.

Copy link
Contributor Author

@S11001001 S11001001 Jul 20, 2020

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" 🙂

Comment on lines -47 to -50
type NameMatcher = String => Boolean
type ValueMatcher = String => Boolean
type Action[T, R, C] = (T, PropertyCursor, String, C) => Either[DotNotFailure, R]

Copy link
Contributor

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?

Copy link
Contributor Author

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
S11001001 added a commit that referenced this pull request Jul 20, 2020
@S11001001
Copy link
Contributor Author

Split -Xlint:doc-detached off to #6802.

Copy link
Contributor

@cocreature cocreature left a comment

Choose a reason for hiding this comment

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

Thanks!

Copy link

@ghost ghost left a 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
Copy link

Choose a reason for hiding this comment

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

What does "/ 0" mean?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Divide by 0.

Copy link

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.

@S11001001 S11001001 merged commit 4355406 into master Jul 21, 2020
@S11001001 S11001001 deleted the more-scalac-2.12-warnings branch July 21, 2020 12:18
mergify bot pushed a commit that referenced this pull request Jul 28, 2020
* add -Xlint:doc-detached

- reverts 1feae96 from #6798

* attach several scaladocs where they'll actually be included

* no changelog

* attach several more scaladocs where they'll actually be included

* no changelog

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

Successfully merging this pull request may close these issues.

None yet

4 participants