summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Group settings should honor user-set individual optionsJason Zaugg2014-02-173-24/+18
| | | | | | | | | | | | | | | In the last commit, we added the ability to explicitly disable boolean settings form the command line. This commit changes group settings (like -optimize), to leave them alone if set explicitly. Examples: `scalac -Xlint -Ywarn-unused:false -optimize -Yinline:false` The mechanism for such settings has also been refactored to `MutableSettings`, to let use reuse this for `-Xlint`.
* Expose a means to disable boolean settingsJason Zaugg2014-02-172-1/+12
| | | | | | Enables `-Yboolean-setting:{true,false}`. This will be exploited in the next commit to enable one to turn off a single component of a group setting, such as `-Xlint` or `-optimize`.
* SI-7707 SI-7712 Exclude unused warnings from -XlintJason Zaugg2014-02-174-5/+9
| | | | | | | | | | | | | | | | | | | | | | Experience building open source projects like Specs that use `-Xlint` suggests that this warning is too noisy to lump in with the others. We are lacking in more fine-grained control of these things, so simply turning of `-Xlint` in favour of its underlying `-Y` options ends up *losing* some other important warnings that are predicated directly on `-Xlint`. Furthermore, bug reports against M8, SI-7707 SI-7712, show that unused private/local warnings, while far less noisy, are still in need of polish. This commit moves these warnings to a pair of new -Y options, neither of which is part of `-Xlint`.. Let's ask people to opt in for 2.11, and as it stabilizes, we can consider adding it to Xlint (or the desirable evolution of that) in the next release.
* Merge pull request #3539 from Blaisorblade/topic/performanceGrzegorz Kossakowski2014-02-171-1/+1
|\ | | | | Avoid storing source file contents twice
| * Avoid storing source file contents twicePaolo G. Giarrusso2014-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | BatchSourceFile instances contain two almost identical character arrays, content0 and content. What's worse, content0 is even public. Instead, content0 should just be a constructor parameter. This seems the residual of an incomplete refactoring. I observed this waste of memory during debugging; after applying this patch, I've verified by hand that the second field indeed disappears. I don't expect a measurable difference, but this patch is not premature optimization because it makes code more logical.
* | Revert "SI-5920 enables default and named args in macros"Jason Zaugg2014-02-175-88/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d. That commit lead to an error compiling Specs2: [info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import [info] [warn] import DiffShortener._ [info] [warn] ^ [info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion: [info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition [info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53) [info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131) [info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126) [info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25) [info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
* | Merge pull request #3397 from xeno-by/ticket/5920Jason Zaugg2014-02-1616-89/+135
|\ \ | | | | | | SI-5920 enables default and named args in macros
| * | SI-5920 enables default and named args in macrosEugene Burmako2014-02-105-66/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When producing an initial spec for macros two years ago, we sort of glossed over named/default arguments in macro applications, leaving them for future work. Once the aforementioned future has come, I’ve made several attempts at making things operational (e.g. last summer), but it’s always been unclear how to marry the quite complex desugaring that tryNamesDefaults performs with the expectations of macro programmers to see unsugared trees in macro impl parameters. Here’s the list of problems that arise when trying to encode named/default arguments of macro applications: 1) When inside macro impls we don’t really care about synthetic vals that are typically introduced to preserve evaluation order in non-positional method applications. When we inline those synthetics, we lose information about evaluation order, which is something that we wouldn’t like to lose in the general case. 2) More importantly, it’s also not very exciting to see invocations of default getters that stand for unspecified default arguments. Ideally, we would like to provide macro programmers with right-hand sides of those default getters, but that is: a) impossible in the current implementation of default parameters, b) would anyway bring scoping problems that we’re not ready to deal with just yet. Being constantly unhappy with potential solutions to the aforementioned problems, I’ve been unable to nail this down until the last weekend, when I realized that: 1) even though we can’t express potential twists in evaluation order within linearly ordered macro impl params, we can use c.macroApplication to store all the named arguments we want, 2) even though we can’t get exactly what we want for default arguments, we can represent them with EmptyTree’s, which is not ideal, but pretty workable. That’s what has been put into life in this commit. As a pleasant side-effect, now the macro engine doesn’t have to reinvent the wheel wrt reporting errors about insufficient arg or arglist count. Since this logic is intertwined with the tryNamesDefaults desugaring, we previously couldn’t make use of it and had to roll our own logic that checked that the number of arguments and parameters of macro applications correspond to each other. Now it’s all deduplicated and consistent.
| * | introduces -Yshow-symownersEugene Burmako2014-02-108-40/+58
| | | | | | | | | | | | | | | | | | This facility, along with -Yshow-syms, has proven to be very useful when debugging problems caused by corrupt owner chains when hacking on named/default argument transformation.
| * | deduplication in Symbol.nameStringEugene Burmako2014-02-101-2/+1
| | | | | | | | | | | | | | | Since now it uses idString to print out the id part of the name when -uniqid is turned on, instead of duplicating the code from idString.
| * | standardizes checks for default gettersEugene Burmako2014-02-103-2/+7
| | |
| * | standardizes prefixes used in named/default desugaringEugene Burmako2014-02-102-2/+4
| | |
* | | Merge pull request #3499 from densh/topic/single-element-tupleEugene Burmako2014-02-162-8/+6
|\ \ \ | | | | | | | | Make handling of tuples more consistent in quasi-quotes
| * | | Make handling of tuples more consistent in quasi-quotesDenys Shabalin2014-02-102-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On one hand we know that q"($expr)" is the same as q"$expr". On the other if we wrap it into a list and splice as q"(..$expr)" we get a Tuple1 constructor call which is inconsistent. This pull request fixes this inconsistency by making q"(..$expr)" being equivalent q"(${expr.head})" for single-element list. We also add support for matching of expressions as single-element tuples (similarly to blocks) and remove liftables and unliftables for Tuple1 (which aren't clearly defined any longer due to q"(foo)" == q"foo" invariant).
* | | | Merge pull request #3521 from xeno-by/ticket/8270Jason Zaugg2014-02-165-307/+362
|\ \ \ \ | | | | | | | | | | SI-8270 unconfuses bundles and vanilla macros
| * | | | SI-8270 unconfuses bundles and vanilla macrosEugene Burmako2014-02-135-307/+362
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a mistake in macro impl ref typechecking that used to have an heuristic to figure out whether it looks at a bundle method ref or at a vanilla object method ref. Under some circumstances the heuristic could fail, and then the macro engine would reject perfectly good macro impls. Now every macro impl ref is typechecked twice - once as a bundle method ref and once as a vanilla object method ref. Results are then analyzed, checked against ambiguities (which are now correctly reported instead of incorrectly prioritizing towards bundles) and delivered to the macro engine. The only heuristic left in place is the one that's used to report errors. If both bundle and vanilla typechecks fail, then if a bundle candidate looks sufficiently similar to a bundle, a bundle typecheck error is reported providing some common bundle definition hints.
* | | | | Merge pull request #3513 from xeno-by/topic/typecheck-member-defsJason Zaugg2014-02-163-66/+63
|\ \ \ \ \ | | | | | | | | | | | | typecheck(q"class C") no longer crashes
| * | | | | typecheck(q"class C") no longer crashesEugene Burmako2014-02-123-66/+63
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MemberDefs alone can't be typechecked as is, because namer only names contents of PackageDefs, Templates and Blocks. And, if not named, a tree can't be typed. This commit solves this problem by wrapping typecheckees in a trivial block and then unwrapping the result when it returns back from the typechecker.
* | | | | Merge pull request #3455 from densh/topic/patdefEugene Burmako2014-02-1610-94/+170
|\ \ \ \ \ | | | | | | | | | | | | Fix SI-8202 and improve support for splicing patterns into vals
| * | | | | Improve support for patterns in valsDenys Shabalin2014-02-096-37/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commits adds construction-only support for splicing patterns into vals (a.k.a. PatDef). Due to non-locality of the desugaring it would have been quite expensive to support deconstruction as the only way to do it with current trees is to perform implodePatDefs transformation on every single tree.
| * | | | | Move null check case higher to avoid NPEDenys Shabalin2014-02-091-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | Also use sym.isErrorneous instead of manual name check.
| * | | | | Move placeholder construction logic into PlaceholdersDenys Shabalin2014-02-093-30/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously construction logic used to be in Parsers and deconstruction in Placeholders making it easy to forget one if you change the other.
| * | | | | SI-8202 bug compatibility with SI-8211 for quasiquotesDenys Shabalin2014-02-093-1/+9
| | |/ / / | |/| | |
* | | | | Merge pull request #3493 from retronym/ticket/3452-2Grzegorz Kossakowski2014-02-163-262/+166
|\ \ \ \ \ | | | | | | | | | | | | SI-3452 Correct Java generic signatures for mixins, static forwarders
| * | | | | SI-3452 GenBCode version of the static-forwarder signature fixJason Zaugg2014-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Shares the code with the GenASM version of the fix.
| * | | | | SI-3452 Reduce low-hanging duplication bewteen GenASM and GenBCodeJason Zaugg2014-02-152-123/+4
| | | | | |
| * | | | | SI-3452 Refactoring code in GenASMJason Zaugg2014-02-151-145/+146
| | | | | | | | | | | | | | | | | | | | | | | | For a non copypasta for of reuse in GenBCode.
| * | | | | SI-3452 A better fix for static forwarder generic sigsJason Zaugg2014-02-151-15/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit fixed this in the wrong way. The addition to the test case (testing an inherited method from a base class in addition to the test with a mxin method) still failed. Like mixin, static forwarder generation uses the exact erased siganture of the forwardee for the forwarder. It really ought to use the as-seen-from signature (adding requisite boxing/ unboxing), but until we do that we have to avoid emitting generic signatures that are incoherent.
| * | | | | SI-3452 Correct Java generic signatures for mixins, static forwardersJason Zaugg2014-02-092-12/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Parts of this patch and some of the commentary are from @paulp] This took me so long to figure out I can't even tell you. Partly because there were two different bugs, one which only arose for trait forwarders and one for mirror class forwarders, and every time I'd make one set of tests work another set would start failing. The runtime failures associated with these bugs were fairly well hidden because you usually have to go through java to encounter them: scala doesn't pay that much attention to generic signatures, so they can be wrong and scala might still generate correct code. But java is not so lucky. Bug #1) During mixin composition, classes which extend traits receive forwarders to the implementations. An attempt was made to give these the correct info (in method "cloneBeforeErasure") but it was prone to giving the wrong answer, because: the key attribute which the forwarder must capture is what the underlying method will erase to *where the implementation is*, not how it appears to the class which contains it. That means the signature of the forwarder must be no more precise than the signature of the inherited implementation unless additional measures will be taken. This subtle difference will put on an unsubtle show for you in test run/t3452.scala. trait C[T] trait Search[M] { def search(input: M): C[Int] = null } object StringSearch extends Search[String] { } StringSearch.search("test"); // java // java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC; The principled thing to do here would be to create a pair of methods in the host class: a mixin forwarder with the erased signature `(String)C[Int]`, and a bridge method with the same erased signature as the trait interface facet. But, this turns out to be pretty hard to retrofit onto the current setup of Mixin and Erasure, mostly due to the fact that mixin happens after erasure which has already taken care of bridging. For a future, release, we should try to move all bridging after mixin, and pursue this approach. But for now, what can we do about `LinkageError`s for Java clients? This commit simply checks if the pre-erasure method signature that we generate for the trait forward erases identically to that of the interface method. If so, we can be precise. If not, we emit the erased signature as the generic signature. Bug #2) The same principle is at work, at a different location. During genjvm, objects without declared companion classes are given static forwarders in the corresponding class, e.g. object Foo { def bar = 5 } which creates these classes (taking minor liberties): class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 } class Foo { static def bar = Foo$.MODULE$.bar } In generating these, genjvm circumvented the usual process whereby one creates a symbol and gives it an info, preferring to target the bytecode directly. However generic signatures are calculated from symbol info (in this case reusing the info from the module class.) Lacking even the attempt which was being made in mixin to "clone before erasure", we would have runtime failures of this kind: abstract class Foo { type T def f(x: T): List[T] = List() } object Bar extends Foo { type T = String } Bar.f(""); // java // java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List; Before/after this commit: < signature f (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>; --- > signature f (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>; This takes the warning count for compiling collections under `-Ycheck:jvm` from 1521 to 26.
* | | | | | Merge pull request #3511 from som-snytt/issue/interp-octalAdriaan Moors2014-02-152-4/+58
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-8266 Deprecate octal escapes in f-interpolator
| * | | | | | SI-8266 Deprecate octal escapes in f-interpolatorSom Snytt2014-02-112-4/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also turns the f-interpolator into a migration assistant by suggesting alternatives for the standard escapes.
* | | | | | | Merge pull request #3528 from Ichoran/issue/6908Adriaan Moors2014-02-151-4/+4
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | SI-6908 FlatHashTable and things that depend on it can't store nulls
| * | | | | | | Made ParFlatHashTableIterator private vars private[this].Rex Kerr2014-02-151-3/+3
| | | | | | | |
| * | | | | | | SI-6908 FlatHashTable and things that depend on it can't store nullsRex Kerr2014-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed ParFlatHashTable to use entryToElem which correctly converts sentinels to nulls.
* | | | | | | | Merge pull request #3527 from Ichoran/issue/8264Adriaan Moors2014-02-152-6/+7
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-8264 scala.collection.immutable.HashSet#- returns broken Set
| * | | | | | | | SI-8264 scala.collection.immutable.HashSet#- returns broken SetRex Kerr2014-02-142-6/+7
| |/ / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Was an error in HashSet's handling of removal of an element when a HashTrieSet should turn into a HashSet1. Also slightly modified HashMap's filter0 to more closely match HashSet (by adding the same comment).
* | | | | | | | Merge pull request #3443 from gourlaysama/man-pagesAdriaan Moors2014-02-151-0/+3
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | add -Xsource:version to scalac man page
| * | | | | | | | add -Xsource:version to scalac man pageAntoine Gourlay2014-01-311-0/+3
| | |_|_|_|_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | The flag was added in d43618a (PR #3340) by @huitseeker.
* | | | | | | | Merge pull request #3532 from som-snytt/issue/7711Adriaan Moors2014-02-155-13/+10
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-7711 Do not emit extra argv in script body
| * | | | | | | | SI-7711 Test for args in scriptSom Snytt2014-02-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compiles with -Xlint to ensure there are no lurkers. Updates `ScriptTest` to pass args to the script. It's called `argv` partly as homage, partly because `args` is an `Array`.
| * | | | | | | | SI-7711 Do not emit extra argv in script bodySom Snytt2014-02-144-12/+8
| | |_|/ / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take away `argv` and make `args` the standard parameter name. This is a quick fix to avoid "unused local" lint error. All the examples use `args`; in particular, "Step 4. Write some Scala scripts" in "Programming in Scala" uses `args`. I see the footnote there is also where Odersky concatenation is specified, `"Hello, "+ args(0) +"!"` with no space next to the literals. Also removes `argv` from `StdNames`. Was torn whether just to add `argc`. Maybe start a new project to house Names, emeritus.
* | | | | | | | Merge pull request #3533 from adriaanm/t8283Adriaan Moors2014-02-142-41/+80
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-8283 mutation-free bound inference for existentials
| * | | | | | | | SI-8283 mutation-free bound inference for existentialsJason Zaugg2014-02-142-41/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A safer version of the fix for SI-6169 (#3471) Only modify the skolems to avoid leaking the sharper bounds to `quantified`. The included test case was minimized from akka-camel (src/main/scala/akka/camel/Consumer.scala).
* | | | | | | | | Merge pull request #3531 from Ichoran/issue/8188Adriaan Moors2014-02-141-2/+2
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | SI-8188 NPE during deserialization of TrieMap
| * | | | | | | | | SI-8188 NPE during deserialization of TrieMapRex Kerr2014-02-141-2/+2
| | |_|_|/ / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
* | | | | | | | | Merge pull request #3530 from Ichoran/issue/6632Adriaan Moors2014-02-141-1/+4
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | SI-6632 ListBuffer's updated accepts negative positions
| * | | | | | | | | SI-6632 ListBuffer's updated accepts negative positionsRex Kerr2014-02-131-1/+4
| |/ / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed the behavior in SeqLike.updated (which would silently accept negatives and throw on empty.tail) to throw IndexOutOfBoundException. Updated tests to verify the behavior in ListBuffer. Everything else SeqLike will come along for the ride.
* | | | | | | | | Merge pull request #3525 from adriaanm/t8177bAdriaan Moors2014-02-142-19/+39
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | SI-8177 specializeSym must use memberInfo on high side
| * | | | | | | | | SI-8177 tidy up in type reificationEugene Burmako2014-02-142-4/+2
| | | | | | | | | |
| * | | | | | | | | SI-8177 specializeSym must use memberInfo on high sideAdriaan Moors2014-02-133-19/+41
| |/ / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When determining whether member `symLo` of `tpLo` has a stronger type than member `symHi` of `tpHi`, should we use memberType or memberInfo? Well, memberType transforms (using `asSeenFrom`) `sym.tpe`, whereas memberInfo performs the same transform on `sym.info`. For term symbols, this ends up being the same thing (`sym.tpe == sym.info`). For type symbols, however, the `.info` of an abstract type member is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol, so that `sym.tpe <:< sym.info`, but not the other way around. Thus, for the strongest (correct) result, we should use `memberType` on the low side. On the high side, we should use the result appropriate for the right side of the `<:<` above (`memberInfo`). I also optimized the method a little bit by avoiding calling memberType if the symbol on the high side isn't eligble (e.g., it's a class). PS: I had to add a workaround to reifyType, because we now dealias a little less eagerly, which means a type selection on refinement class symbols makes it to reify this broke the t8104 tests. I also had to update the run/t6992 test, which should now test the right thing. Tests should be commented and/or use sensible names. What is it testing? What is the expected outcome? We should not be left guessing.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-06 14:36:03 +0000