Add new configuration options to Disable rule #601

vovapolu · 2018-02-05T21:58:42Z

Initial issue #598.

This PR adds new configuration options

Disable.ifSynthetic: to disable symbols in expanded implicits and macro code
Disable.unlessInside: superseding the old DisableUnless rule.

Additionally, this PR refines Disable to discard non-significant references to banned symbols such as imports.

olafurpg · 2018-02-09T15:01:12Z

scalafix-core/shared/src/main/scala/scalafix/internal/config/DisableConfig.scala

+      "When true also blocks symbols in the generated code. Default to false. " +
+        "Ignored if unlessInsideBlock is specified.")
+    unlessSynthetic: Boolean,
+    @Description("The unsafe that are banned unless inside a 'safe' block")


unsafe symbols

olafurpg · 2018-02-12T13:04:22Z

scalafix-core/shared/src/main/scala/scalafix/internal/config/DisableConfig.scala

+                    |    ]
+                    |  }
+                    |  { // unlessInsideBlock mode
+                    |    unlessInsideBlock = "com.IO"


Can we remove this example? I think it's enough to have one example and scala.util.Try seems like the most easy to understand

olafurpg · 2018-02-12T13:05:09Z

scalafix-tests/input/src/main/scala/test/DisableSimple.scala

@@ -49,7 +59,7 @@ case object Disable {
  }
  val yy = AA.asInstanceOf // OK, no errors
  Option(1).get /* assert: Disable.Option.get
-            ^
+  ^


Why this change? The caret should point to get

I use ctx.index.symbol(tree) to get symbol during tree traversal. Looking at sources for this method we have case Term.Select(_, name @ Name(_)) => symbol(name) :)

We should report only on the Name, if you are in a pattern match the best way to do it is with case index.Symbol(tree: Name) => ...

olafurpg · 2018-02-12T13:08:08Z

scalafix-core/shared/src/main/scala/scalafix/internal/config/DisableConfig.scala

-    symbols: List[CustomMessage[Symbol.Global]] = Nil
+    @Description("The list of disable configurations")
+    @ExampleValue("""[
+                    |  { // default mode


We should preserve the old syntax for Disable.symbols, the new layout is not user-friendly

Disable.parts = [ { symbols = [ ... ]} ]

Instead of parts, I would prefer

Disable.symbols = [...] Disable.unlessSynthetic = [ ... ] Disable.unlessInsideBlock = [ ... ]

I'm confused by how unlessSynthetic works here. Is it a "disable this even if it is synthetic" setting? Neither symbols nor unless should operate on synthetic symbols.

olafurpg · 2018-02-12T13:11:46Z

website/src/main/tut/docs/rules/Disable.md

@@ -5,10 +5,22 @@ title: Disable

 # Disable

-_Since 0.5.0_
+_Since 0.6.0_


Let's keep this unchanged and create a new "v0.6.0" section at the bottom that describes the new configuration options.

The website goes live as soon as this is merged so we should not immediately replace the v0.5 documentation, that would be confusing for users.

Hmm, how can we keep the old version if we generate it automatically?

The stable version is currently hardcoded for 0.5.10 https://scalacenter.github.io/scalafix/docs/users/installation had to do that before releasing 0.6.0-M1 #610

And how we can describe the new format then? :D

Copy paste the current generated markdown file and inline it. You'll need to generate the site first.

olafurpg · 2018-02-12T13:13:02Z

website/src/main/tut/docs/rules/DisableUnless.md

@@ -1,62 +0,0 @@
---
-layout: docs


Instead of removing this file we should add a note saying this rule has been merged with Disable and include migration instructions. People may have linked to this page so we should not return 404.

fommil · 2018-02-19T22:00:10Z

Any more comments on this?

olafurpg

Had a partial review yesterday that I forgot to submit. Took another round today and found more comments.

In the future, please try to use more descriptive commit messages @vovapolu. A large commit doing multiple things with a commit message "Fixes" makes it difficult to review. A list of high level bullet would help a lot, something like

Address review feedback

Keep old DisableUnless.md

Rename foo to bar

Update description for setting X

olafurpg · 2018-02-19T09:21:14Z

scalafix-core/shared/src/main/scala/scalafix/internal/config/DisableConfig.scala

+                    |[
+                    |  {
+                    |    symbol = "scala.Any.asInstanceOf"
+                    |    message = "use patter-matching instead"


olafurpg · 2018-02-20T07:38:50Z

scalafix-core/shared/src/main/scala/scalafix/internal/rule/Disable.scala

+        Right(config.allSymbols) // reset blocked symbols in def
+      case (_: Term.Function, _) =>
+        Right(config.allSymbols) // reset blocked symbols in (...) => (...)
+      case (t: Name, blockedSymbols) if treeIsBlocked(t, blockedSymbols) =>


case (ctx.index.Symbol(t: Name), ... instead of val Some(...) =

SymbolMatcher implements unapply(Tree), so this can even be simplified to something like

val badSymbol = SymbolMatcher.normalized(blockedSymbols:_*) ... case (badSymbol(t: Name), ... =>

As a general note, the scalafix API typically tries to make it possible to guard against stuff in the pattern instead of the guard.

@olafurpg blockedSymbols isn't static, it changes during tree traversal.

You can construct a new SymbolMatcher whenever it changes https://github.com/scalacenter/scalafix/blob/master/scalafix-core/shared/src/main/scala/scalafix/util/SymbolMatcher.scala

val Some(...) = ... is a sign that you were not able to prove to the compiler this deconstruction can't fail. By using SymbolMatcher.unapply you don't need to outsmart the typechecker.

Yeah, I agree with val Some(...) = ....

Why can't you ignore cases when the tree isn't blocked with SymbolMatcher?

Well, in SearcherWithContext I need to return new context or LintError, ignoring means no changing in the context. I could just return an old context... I didn't want to do this :)

I'm not sure I follow why SymbolMatcher is not suitable here but I trust your judgment 😉 we can keep it unchanged

I can change it to what you want, maybe it will be more understandable.

Hehe, IDEA can't parse case (ctx.index.Symbol(t: Name), ...

olafurpg · 2018-02-20T07:43:42Z

website/src/main/tut/docs/rules/Disable.md

@@ -5,6 +5,94 @@ title: Disable

 # Disable

+_Since 0.6.0_


Let's keep the current docs at the top and the "Since v0.6.0" part at the bottom. I expect v0.6.0 to get released in a couple weeks from now so having this at the top would be confusing for users who visit the website today.

olafurpg · 2018-02-20T07:46:55Z

website/src/main/tut/docs/rules/Disable.md

+
+#### UnlessInsideBlock
+
+<table><thead><tr><th>Name</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td><code>unless</code></td><td>Symbol</td><td>The symbol that indicates a 'safe' block.</td></tr><tr><td><code>symbols</code></td><td>List[Message[Symbol]]</td><td>The unsafe symbols that are banned unless inside a 'safe' block</td></tr></tbody></table>


This looks like configuration for the new rule. We should copy-paste the configuration for the old rule so keep the Disable site is unchanged for the "since v0.5.0" part
It should look like this

Config for the latest version of the rule is auto-generated with the scalafix.website.rule("Disable", DisableConfig.default) line below

olafurpg · 2018-02-20T07:48:57Z

website/src/main/tut/docs/rules/DisableUnless.md

@@ -5,6 +5,10 @@ title: DisableUnless

 # DisableUnless

+_Since 0.6.0_
+
+This rule was merge into `Disable`. See `Disable` docs for more details.


NOTE. This rule is deprecated and from v0.6.0 onwards will be merged into the {% rule_ref Disable %} rule.

olafurpg · 2018-02-20T09:40:28Z

scalafix-tests/input/src/main/scala/test/DisableUnlessInsideBlock.scala

  {
-    unless = "test.DisableUnless.IO"
+    unless = "test.DisableUnlessInsideBlock.IO"


Should this field be called "safeBlock" or "block" instead of "unless"?

Disable.unlessInsideBlock = [ { safeBlock = "IO", disabledSymbols = ... } ]

?

Any thoughts @fommil ? I personally haven't used this rule, but "unless = X, symbols = YY" seems weird.

the names of these things are starting to get quite big, but I think a lot of symbols will have a shared safeBlock so it makes sense for them to be grouped like this. Each symbol may have a different explanation, though, so as long as that is supported we're good.

olafurpg · 2018-02-20T09:41:05Z

scalafix-core/shared/src/main/scala/scalafix/internal/rule/Disable.scala

+    def filterBlockedSymbolsInBlock(
+        blockedSymbols: List[Symbol.Global],
+        block: Tree): List[Symbol.Global] = {
+      val Some(symbolBlock: Symbol.Global) = ctx.index.symbol(block)


This can crash with MatchError, please refactor to avoid unsafe code.

olafurpg · 2018-02-20T09:44:17Z

scalafix-core/shared/src/main/scala/scalafix/internal/rule/Disable.scala

+  /**
+    * Searches for specific nodes in Tree and adds result of searching to the list.
+    * Also passes context through tree traversal.
+    * fn can either return a value. that stops the searching, or change the context.


@param fn If fn returns Left then XXX. If fn returns Right then YYY.

It's not immediately clear from the signature what fn does.

I know this PR is just moving code around but given that Disable is covering more use-cases after this PR we should try to document better what SearcherWithContext does.

olafurpg · 2018-02-20T09:46:32Z

scalafix-core/shared/src/main/scala/scalafix/internal/rule/Disable.scala

+    * Also passes context through tree traversal.
+    * fn can either return a value. that stops the searching, or change the context.
+    */
+  class SearcherWithContext[T, U](initContext: U)(


ContextTraverser

s/T/Value/
s/U/Context/

?

olafurpg · 2018-02-20T09:47:00Z

scalafix-core/shared/src/main/scala/scalafix/internal/rule/Disable.scala

+object Disable {
+
+  /**
+    * Searches for specific nodes in Tree and adds result of searching to the list.


A tree traverser to collect values with a custom context.

At every tree node, either builds a new context U or returns a new value T to accumulate.
To collect all accumulated values, use result(Tree).

:D I'm not very experienced in writing docs, unfortunately.

* Changes in Disable tree traversal code * SearcherWithContext's renamed to ContextTraverser, the docs are updated * DisableConfig minor renamings * Disable and DisableUnless docs are also updated

olafurpg

Does Disable.ifSynthetic deprecate NoInfer? If so, we should deprecate the NoInfer name and update it's docs to point to Disable in a specific "Since v0.6.0" section.

Only minor comments remaining, this is very close to complete!

olafurpg · 2018-02-26T09:35:20Z

website/src/main/tut/docs/rules/Disable.md

+object Test {
+  val z = 1.asInstanceOf[String] // default mode, not ok
+
+  List(1) + "any2stringadd" // unlessSynthetic mode, not ok


s/unlessSynthetic/ifSynthetic/

Non-executable docs are difficult to maintain, would be nice if we could somehow reuse testkit for docs 🤔

olafurpg · 2018-02-26T09:42:10Z

scalafix-core/shared/src/main/scala/scalafix/internal/config/DisableConfig.scala

+                    |  }
+                    |]
+      """.stripMargin)
+    unlessInsideBlock: List[UnlessInsideBlock] = Nil


What do you think about renaming this to "unlessInsideSafeBlock"? I think it makes sense to be consistent betweeen .unlessInsideBlock and safeBlock =. Standalone "Block" is too generic so I think "safeBlock" may be clearer, but I'll leave it to you and @fommil to decide what makes most sense.

the concept of "safe"ness is perhaps limited to my usecase. I can imagine people wanting to use this for other purposes, such as logging or monitoring, in which case "safe" will be a misnomer. The "block" concept is also a bit of a misnomer because of course it might not be in a block at all but just a regular method call... IO.apply(println("hello world")) has no blocks. So 👍 for unlessInside

Fair enough. What should the "safe symbol" be called then?

Disable.unlessInside = [ ??? ]

olafurpg

Is there any nuke setting to disable a symbol regardless if it's synthetic or not?

Also, should we deprecate NoInfer in favor of Disable.ifSynthetic?

olafurpg · 2018-02-27T09:19:00Z

scalafix-core/shared/src/main/scala/scalafix/internal/config/DisableConfig.scala

-        |  "com.Lib.implicitConversion"
-        |]""".stripMargin)
-    symbols: List[CustomMessage[Symbol.Global]] = Nil
+    @Description("The list of symbols to disable only in the actual sources.")


List of symbols to disable if written explicitly in source. Does not report an error for inferred symbols in macro expanded code or implicits.

olafurpg · 2018-02-27T09:23:53Z

scalafix-core/shared/src/main/scala/scalafix/internal/config/DisableConfig.scala

+                    |]""".stripMargin)
+    symbols: List[CustomMessage[Symbol.Global]] = Nil,
+    @Description(
+      "The list of symbols to disable, also blocks symbols in the generated code")


List of symbols to disable if inferred. Does not report an error for symbols written explicitly in source code.

vovapolu · 2018-02-28T18:45:23Z

Is there any nuke setting to disable a symbol regardless if it's synthetic or not?

Add it to the ifSynthetic and to symbols?

Also, should we deprecate NoInfer in favor of Disable.ifSynthetic?

Why not? :)

fommil · 2018-02-28T20:31:03Z

can we please do any more refinements in a follow up? I'm really keen to try this out in the wild once you cut a release and I fear we will run out of Vladimir's sponsored time by the time I discover anything.

olafurpg · 2018-02-28T20:45:50Z

Add it to the ifSynthetic and to symbols?

That seems a bit tedious for a seemingly common use-case. Would be good to have an option to enable both synthetic and non-synthetic checks and Disable.symbols seems to be the best choice for that.

can we please do any more refinements in a follow up?

Sure, we can do that esp. since we are kind of in between major releases. Keep in mind that the current master is a bit in a limbo in a transition to the new Type and method symbol syntax in semanticdb (https://github.com/scalameta/scalameta/blob/master/semanticdb/semanticdb3/semanticdb3.md#type). The current semanticdb-scalac default options produce both old and new types, which incurs some unnecessary overhead. We released Scalameta v3.4.0 today (https://github.com/scalameta/scalameta/releases/tag/v3.4.0) which flips the defaults to much saner default which will give be a nice speedup since we soon no longer need to persist signatures for all referenced symbols, only definitions in each compilation unit. But it will take ~2 more weeks to complete the refactoring, which includes updating ExplicitResultTypes and some other rewrites.

olafurpg

LGTM 👍 Great refactoring @vovapolu !

I left nitpick comments which I'd like to see addressed in a followup PR. I would also like to see Disable.symbols trigger both synthetic and explicit symbols and Disable.ifExplicit replace the current Disable.symbols.

olafurpg · 2018-02-28T20:49:19Z

website/src/main/tut/docs/rules/Disable.md

+
+It has several different modes:
+- Default mode. In this mode symbols are banned in the actual source code.
+- `unlessInsideBlock`


unlessInside

olafurpg · 2018-02-28T20:49:26Z

website/src/main/tut/docs/rules/Disable.md

+
+  List(1) + "any2stringadd" // ifSynthetic mode, not ok
+
+  Option.empty[Int].get //  unlessInsideBlock mode, not ok


unlessInside

olafurpg · 2018-02-28T20:52:12Z

@fommil I recommend adding scalacOptions -P:semanticdb:signatures:old and -P:semanticdb:denotations:all when you give it a spin. This will no longer be necessary once v0.6.0 final is out.

@vovapolu I can take care of deprecating NoInfer 😄

olafurpg · 2018-02-28T20:54:36Z

I opened #641 to track followup changes on this PR @vovapolu

vovapolu added 7 commits January 25, 2018 22:16

Fix for DisableSyntax.noDefaultArgs

57c0696

merge with upstream

e78ef31

Merge remote-tracking branch 'upstream/master'

3210d68

new Disable format

7d5a70c

Updated Disable docs

6b53f4d

Minor fix in DisableSyntax

17f2802

Minor fix in DisableSyntax

2169950

vovapolu added this to the v0.6.0 milestone Feb 6, 2018

olafurpg suggested changes Feb 12, 2018

View reviewed changes

olafurpg mentioned this pull request Feb 13, 2018

ignore generated (expanded macros) code #604

Closed

Fixes

af4a853

olafurpg suggested changes Feb 20, 2018

View reviewed changes

vovapolu added 2 commits February 24, 2018 01:28

Adress review feedback

63f651d

* Changes in Disable tree traversal code * SearcherWithContext's renamed to ContextTraverser, the docs are updated * DisableConfig minor renamings * Disable and DisableUnless docs are also updated

Unused import

99584b7

vovapolu mentioned this pull request Feb 25, 2018

Regex and hierarchy disabling #634

Closed

olafurpg suggested changes Feb 26, 2018

View reviewed changes

Disable doc minor fix, renamed unlessInsideBlock to unlessInside

fa04da9

olafurpg suggested changes Feb 27, 2018

View reviewed changes

Disable docs minor fix

e95616e

olafurpg approved these changes Feb 28, 2018

View reviewed changes

olafurpg merged commit 21a4668 into scalacenter:master Feb 28, 2018

This was referenced Feb 28, 2018

Deprecate NoInfer #640

Closed

Followup from Disable configuration changes #641

Closed

olafurpg changed the title ~~New Disable format~~ Add new configuration options to Disable rule Apr 11, 2018

olafurpg mentioned this pull request May 30, 2018

New DisableConfig format #598

Closed


		#### UnlessInsideBlock

		<table><thead><tr><th>Name</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td><code>unless</code></td><td>Symbol</td><td>The symbol that indicates a 'safe' block.</td></tr><tr><td><code>symbols</code></td><td>List[Message[Symbol]]</td><td>The unsafe symbols that are banned unless inside a 'safe' block</td></tr></tbody></table>


		List(1) + "any2stringadd" // ifSynthetic mode, not ok

		Option.empty[Int].get // unlessInsideBlock mode, not ok

Add new configuration options to Disable rule #601

Add new configuration options to Disable rule #601

Conversation

vovapolu commented Feb 5, 2018 • edited by olafurpg Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vovapolu Feb 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fommil commented Feb 19, 2018

olafurpg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olafurpg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fommil Feb 26, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olafurpg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vovapolu commented Feb 28, 2018

fommil commented Feb 28, 2018

olafurpg commented Feb 28, 2018

olafurpg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olafurpg commented Feb 28, 2018

olafurpg commented Feb 28, 2018

vovapolu commented Feb 5, 2018 •

edited by olafurpg

Loading

vovapolu Feb 15, 2018 •

edited

Loading

fommil Feb 26, 2018 •

edited

Loading