Closed tek closed 2 years ago
0 files - 3 0 suites - 3 0s :stopwatch: -24s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 3 0 suites - 3 0s :stopwatch: -24s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 3 0 suites - 3 0s :stopwatch: -24s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 3 0 suites - 3 0s :stopwatch: -28s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 3 0 suites - 3 0s :stopwatch: -24s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 3 0 suites - 3 0s :stopwatch: -23s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 3 0 suites - 3 0s :stopwatch: -23s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 3 0 suites - 3 0s :stopwatch: -27s 0 tests - 23 0 :heavy_check_mark: - 23 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
also, needs a bit of refactoring for the compatibilty mess
0 files - 4 0 suites - 4 0s :stopwatch: -25s 0 tests - 24 0 :heavy_check_mark: - 24 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
wow you are fast, I'll try to learn what it takes to keep up with the compiler
0 files - 4 0 suites - 4 0s :stopwatch: -21s 0 tests - 24 0 :heavy_check_mark: - 24 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 4 0 suites - 4 0s :stopwatch: -24s 0 tests - 24 0 :heavy_check_mark: - 24 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 4 0 suites - 4 0s :stopwatch: -26s 0 tests - 24 0 :heavy_check_mark: - 24 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
0 files - 4 0 suites - 4 0s :stopwatch: -25s 0 tests - 24 0 :heavy_check_mark: - 24 0 :zzz: ±0 0 :x: ±0
Results for commit f93f0ae2. ± Comparison against base commit 174ed639.
well it's not much effort to add the analyzer plugin :sweat_smile:
I see what you are doing here. The analyser cannot be defined for the old version - because it has to extend a new Scala class. The old code has to extend other old Scala classes that are no longer safe to extend (with constructor hijacking particularly)
In addition, the name scala_2.13.6+ I used is no longer accurate (we have exclusive code for 2.13.6 now)
All these things put together probably means it is hard to catch the deadline. Would you like me to backport the patch for 2.12.14 compatibility to the previous version and call it a release?
sounds good, yeah. the whole version specific thing is getting real messy.
Maybe it would be sensible to drop all but the latest versions of 12/13 into a legacy branch and add new features only to 2.12.14 and the analyzer plugin, then release the same code for compat for all the older versions or something…
or we could just announce that "the next version won't have 2.13.6 support, please wait for a hotfix"
that's no good, because people have potentially tens of projects at work with different scala versions, and if they have splain in the global sbt config they'd have to screw around with conditionals
done, https://github.com/tek/splain/tree/0.5.8_2.12.14
this should be consistent with latest behaviour in Scala 2.13.6
ok, I made releases for both 2.12.14 and 2.13.6 (with an empty analyzer plugin)
Can relax a bit :)
Would you like to talk about roadmap now? If you think that it will be too hard or time consuming to maintain 2 versions (splain and scalac), you can simply declare that 0.5.8 is the last release, and all upcoming patches should directly goes to scala compiler
WTF? When the code was copied to scalac, all automated tests are omitted.
Not cool man, it loses its most valuable asset
what was copied to scalac?
regarding roadmap – if we strip down to just the features that aren't in scala, it shouldn't be that much effort. assuming we can get this to be ergonomic
what was copied to scalac?
All the production code in scala compiler project, in the following package:
package scala.tools.nsc
package typechecker
package splain
They are copied from this repo. Yet all the unit tests are omitted which makes it impossible to maintain. So obviously you can choose to delete all the code that are already copied, but not before some of us submitting a patch that include all the missing tests (and latest patch on splain 0.5.9). Otherwise, the component will quickly be destroyed by junior PhD students :)
If you want my suggestion, I would recommend setting the current version DIRECTLY TO 1.0-SNAPSHOT, and declare it NOT backward compatible with scala 2.13.5-:
Not sure this is what you mean, but the unit tests are now partests, for example: https://github.com/scala/scala/blob/2.13.x/test/files/run/splain.scala
Regarding your suggestion with the version – sounds good, please go ahead!
alright, it still strikes me as undisciplined, a project of this size should always put implementation and test code in the same package.
let me edit directly on you branch for the first PR
Did you hardcode all the configurations?
val opts: mutable.Map[String, String] = mutable.Map(
keyAll -> "true",
keyImplicits -> "true",
keyFoundReq -> "true",
keyInfix -> "true",
keyBounds -> "false",
keyColor -> "true",
keyBreakInfix -> "0",
keyCompact -> "false",
keyTree -> "true",
keyBoundsImplicits -> "true",
keyTruncRefined -> "0",
keyRewrite -> "",
keyKeepModules -> "0",
)
Was it because they are already in scalac and you haven't figure out a way to read them?
In scalac it is also hardcoded to 70.
Did you make some political rivals in scala team?
Did you hardcode all the configurations?
what do you mean by "hardcode"? those are the defaults that have always been like this
and I'm not sure why the 70 was chosen there…
I'm talking about this part:
val keyAll = "all"
val keyImplicits = "implicits"
val keyFoundReq = "foundreq"
val keyInfix = "infix"
val keyBounds = "bounds"
val keyColor = "color"
val keyBreakInfix = "breakinfix"
val keyCompact = "compact"
val keyTree = "tree"
val keyBoundsImplicits = "boundsimplicits"
val keyTruncRefined = "truncrefined"
val keyRewrite = "rewrite"
val keyKeepModules = "keepmodules"
val opts: mutable.Map[String, String] = mutable.Map(
keyAll -> "true",
keyImplicits -> "true",
keyFoundReq -> "true",
keyInfix -> "true",
keyBounds -> "false",
keyColor -> "true",
keyBreakInfix -> "0",
keyCompact -> "false",
keyTree -> "true",
keyBoundsImplicits -> "true",
keyTruncRefined -> "0",
keyRewrite -> "",
keyKeepModules -> "0"
)
def opt(key: String, default: String) = opts.getOrElse(key, default)
as you can see, the opts cannot be changed and wasn't read from any external option
Just for curiosity: do you prefer VSCode over IntelliJ IDEA?
Asking because IntelliJ IDEA is mostly a Java IDE, so its indexing is optimised for FileName==ClassName
convention which is totally optional in Scala
I'm thinking of breaking one big file into several smaller one that complies with this convention, but only if you feel comfortable with it.
Also, this is where 70 came from:
val breakInfixLength: Int = 70
In SplainFormatting
, scalac.
I've already complained on their feature forum:
We should move discussion there to engage more people.
Just for curiosity: do you prefer VSCode over IntelliJ IDEA?
Asking because IntelliJ IDEA is mostly a Java IDE, so its indexing is optimised for
FileName==ClassName
convention which is totally optional in ScalaI'm thinking of breaking one big file into several smaller one that complies with this convention, but only if you feel comfortable with it.
I only use neovim, and I'd be fine with breaking files up
Also, this is where 70 came from:
I meant that I don't remember why it was set to 70 in the PR
OK this PR should already be included in #66, closing
this is not complete yet, just a skeleton with the shapeless record formatter.
turns out the plugin hook is a bit crude, still need to override and coerce types…