summaryrefslogtreecommitdiff
path: root/test/files/run
Commit message (Collapse)AuthorAgeFilesLines
* Closes SI-6358. Move accessor generation for lazy vals to typers.Hubert Plociniczak2012-10-182-0/+16
| | | | | | | | | | | | | Until now lazy accessors were handled somehow special because their symbol was created in typers but the corresponding tree was only added in Refchecks. This irregularity caused serious problems for value classes. Also it now looks just better when lazy value is treated in a similar way as other fields. I needed to adapt reifier so that it handles the new implementation correctly. Previously it had to recreate lazy val only by removing defdef and renaming. Now we basically need to recreate lazy val from scratch. There is one minor change to cps plugin but that is still fine because lazy vals were never really part of the transformation. Some range positions needed to be fixed manually. We could do it at the creation time but that would require a lot more "if (symbol.isLazy)" conditions for MethodSyntheis and Symbol/Tree creation and would just unnecessary complicate api. If someone has a better idea, please speak up. Range positions changes were necessary because previously accessors were created at refchecks and they weren't checked by validator (even though they were wrong). This commit removes lazy val implementation restriction introduced for 2.10.0. (cherry-picked from 981424b)
* Merge pull request #1483 from gkossakowski/SI-6440Josh Suereth2012-10-102-0/+8
|\ | | | | SI-6440: Revert change to `TraversableLike.filterNot`
| * SI-6440: Revert change to `TraversableLike.filterNot`Grzegorz Kossakowski2012-10-092-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit df9f470f14262b9b1002f022c2620d8c38835805 introduced a change to `TraversableLike.filterNot` which broke Stream implementation that does override `filter` implementation but does not override `filterNot` implementation. This shows clearly that reusing code for strict and non-strict collections is very problematic. Added a test-case covering this problem. Closes SI-6440. Review by @retronym.
* | Merge pull request #1458 from scalamacros/pullrequest/reflectionJosh Suereth2012-10-094-4/+16
|\ \ | |/ |/| Another reflection bomb
| * removes EmptyTermName and EmptyTypeNameEugene Burmako2012-10-031-1/+1
| | | | | | | | We have nme.EMPTY and tpnme.EMPTY for that.
| * renames macros.TypeError to TypecheckExceptionEugene Burmako2012-10-031-1/+1
| | | | | | | | | | | | | | | | | | Again, this is not a fatal error, so it should end with an Error, and it should subclass not Throwable, but Exception. Also moved the exception outside the cake to simplify error handling, along the same lines of what've been done for parsing and reification exceptions.
| * turns on documentation of scala.reflect.runtimeEugene Burmako2012-10-032-2/+14
| | | | | | | | | | | | | | | | We definitely need to document scala.reflect.runtime.universe, therefore adding scala.reflect.runtime to skipPackages was a mistake. But then we need to make a bunch of internal classes private to reflect or to scala. Not very pretty, but it works.
* | Merge pull request #1442 from adriaanm/ticket-6215Grzegorz Kossakowski2012-10-081-8/+8
|\ \ | | | | | | SI-6215 Fix compiler crash on private method in value class
| * | SI-6215 Fix compiler crash on private method in value classMartin Odersky2012-10-021-8/+8
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the problem with private defs in value classes by moving the $extension after the name proper rather than before. The previous scheme did not commute with makeNonPrivate: I.e. if -ext-> is "generate extension name" and -mnp-> is "make not private" we did get for method foo in value class Foo: foo -ext-> extension$foo -mnp-> Foo$$extension$foo but foo -mnp-> Foo$$foo -ext-> extension$Foo$$foo With the change both variations give the same name: foo -ext-> foo$extension -mnp-> Foo$$foo$extension but foo -mnp-> Foo$$foo -ext-> Foo$$foo$extension
* | MethodSymbol.params => MethodSymbol.paramssEugene Burmako2012-10-073-12/+12
| | | | | | | | | | | | | | | | This matter was discussed at scala-internals: http://groups.google.com/group/scala-internals/browse_thread/thread/6414d200cf31c357 And I am convinced with Paul's argument: consistency of the convention is very important.
* | undeprecates manifests for 2.10.0Eugene Burmako2012-10-032-0/+16
|/ | | | | | | | Since scala-reflect.jar is going to be declared experimental for 2.10.0, it doesn't make sense to deprecate manifests in favor of type tags. Class manifests, however, ARE deprecated for class tags, because class tags don't require scala-reflect.jar and are generated independently of type tags.
* Merge pull request #1415 from scalamacros/is-value-typeEugene Burmako2012-09-288-0/+99
|\ | | | | a fork of isValueType and isNonValueType
| * fully initializes symbols on `typeSignature`Eugene Burmako2012-09-281-1/+1
| | | | | | | | | | | | only affects runtime reflection, because Symbol.typeSignature is only defined in the reflection API. the rest of the compiler uses Symbol.info instead.
| * Fix for failing test.Paul Phillips2012-09-282-7/+18
| | | | | | | | | | | | | | | | | | | | There's some very sketchy behavior visible - I'm printing a method signature and getting this: [B <: <?>, That <: <?>](f: <?>)(implicit cbf: <?>)That But there's no exposed way to force the info. Am I supposed to call isSealed or something?
| * Implementations of isValueType and isNonValueType.Paul Phillips2012-09-283-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Restrictions regarding how non-value types can be used have generally not been enforced explicitly, depending instead on the fact that the compiler wouldn't attempt to use them in strange ways like offering a method type as a type argument. Since users can now create most types from scratch, it has become important to enforce the restrictions in a more direct fashion. This was a lot harder than it probably should have been because there are so many types which go unmentioned by the specification. Hopefully a useful exercise in any case.
| * SI-6417 correctly reifies non-value typesEugene Burmako2012-09-284-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we're reifying non-value types (e.g. MethodTypes), we can't use them as type arguments for TypeTag/WeakTypeTag factory methods, otherwise the macro expansion won't typecheck: http://groups.google.com/group/scala-internals/browse_thread/thread/2d7bb85bfcdb2e2 This situation is impossible if one uses only reify and type tags, but c.reifyTree and c.reifyType exposes in the macro API let anyone feed anything into the reifier. Therefore I now check the tpe that is about to be used in TypeApply wrapping TypeTag/WeakTypeTag factory methods and replace it with AnyTpe if it doesn't fit.
| * showRaw no longer crashes on NoSymbolEugene Burmako2012-09-282-0/+6
| |
* | Merge pull request #1347 from soc/SI-6380Grzegorz Kossakowski2012-09-282-0/+27
|\ \ | |/ |/| SI-6380 Add @throws[Exception]
| * SI-6380 #1 Add @throws[Exception]Simon Ochsenreither2012-09-212-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change allows an additional notation of the @throws annotation: Old-style: @throws(classOf[Exception]) New-style: @throws[Exception] The optional String argument moves @throws in line with @deprecated, @migration, etc. and prevents confusion caused by the default inheritance of ScalaDoc comments and the non-inheritance of annotations. Before: /** This method does ... * @throws IllegalArgumentException if `a` is less than 0. */ @throws(classOf[IllegalArgumentException]) def foo(a: Int) = ... Now: /** This method does ... */ @throws[IllegalArgumentException]("if `a` is less than 0") def foo(a: Int) = ... ScalaDoc @throws tags remain supported for cases where documentation of thrown exceptions is needed, but are not supposed to be added to the exception attribute of the class file. In this commit the necessary compiler support is added. The code to extract exceptions from annotations is now shared instead of being duplicated all over the place. The change is completely source and binary compatible, except that the code is now enforcing that the type thrown is a subtype of Throwable as mandated by the JVM spec instead of allowing something like @throws(classOf[String]). Not in this commit: - ScalaDoc support to add the String argument to ScalaDoc's exception list - Adaption of the library
* | Merge pull request #1399 from paulp/210-uncheckedGrzegorz Kossakowski2012-09-281-5/+5
|\ \ | | | | | | Much better unchecked warnings.
| * | Improvements to unchecked warnings.Paul Phillips2012-09-251-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Closes SI-6275, SI-5762. The comment says is better than I can. /** On pattern matcher checkability: * * Consider a pattern match of this form: (x: X) match { case _: P => } * * There are four possibilities to consider: * [P1] X will always conform to P * [P2] x will never conform to P * [P3] X <: P if some runtime test is true * [P4] X cannot be checked against P * * The first two cases correspond to those when there is enough static * information to say X <: P or that !(X <: P) for all X and P. * The fourth case includes unknown abstract types or structural * refinements appearing within a pattern. * * The third case is the interesting one. We designate another type, XR, * which is essentially the intersection of X and |P|, where |P| is * the erasure of P. If XR <: P, then no warning is emitted. * * Examples of how this info is put to use: * sealed trait A[T] ; class B[T] extends A[T] * def f(x: B[Int]) = x match { case _: A[Int] if true => } * def g(x: A[Int]) = x match { case _: B[Int] => } * * `f` requires no warning because X=B[Int], P=A[Int], and B[Int] <:< A[Int]. * `g` requires no warning because X=A[Int], P=B[Int], XR=B[Int], and B[Int] <:< B[Int]. * XR=B[Int] because a value of type A[Int] which is tested to be a B can * only be a B[Int], due to the definition of B (B[T] extends A[T].) * * This is something like asSeenFrom, only rather than asking what a type looks * like from the point of view of one of its base classes, we ask what it looks * like from the point of view of one of its subclasses. */
* | | moves Context.runtimeUniverse to TreeBuild.mkRuntimeUniverseRefEugene Burmako2012-09-273-4/+7
| | | | | | | | | | | | Scaladoc-driven cleanup for the win
* | | simplifies Context.Run and Context.CompilationUnitEugene Burmako2012-09-271-2/+1
| | | | | | | | | | | | | | | By turning them from abstract types into full-fledged traits implemented by our internal Run and CompilationUnit.
* | | exposes Position.source as SourceFileEugene Burmako2012-09-272-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was useful to pretend that SourceFile isn't a part of the API, when it's physical location was in scala-compiler.jar. Afterwards Position and SourceFile have been moved to scala-reflect.jar, and (what's more important) scala-reflect.jar gained experimental status, meaning that we're not bound by backward compatibility in 2.10.0. Therefore I'd say we should expose a full-fledged SourceFile in Position.source (just as we do for Symbol.associatedFile) and later find out how to strip down its interface to something suitable for public consumption.
* | | removes extraneous stuff from macros.InfrastructureEugene Burmako2012-09-271-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libraryClassLoader can be derived from currentClassPath currentMacro can be trivially derived from macroApplication Backend-detection methods forXXX (as in forJVM or forScaladoc) might be useful, but current design of this API is not future-proof. I'm not able to come up with a better design on the spot, so let's remove this functionality for the moment.
* | | removes front ends from scala-reflect.jarEugene Burmako2012-09-273-13/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was an interesting idea to give macro developers control over front ends, but it hasn't given any visible results. To the contrast, front ends have proven useful for toolboxes to easily control what errors get printed where. Therefore I'm moving front ends to scala-compiler.jar to clean up the API. Yay for scaladoc-driven development!
* | | MirrorOf => MirrorEugene Burmako2012-09-274-8/+8
| | | | | | | | | | | | | | | The name looks weird in the scaladoc overview panel, so I decided to do a last-minute rename.
* | | Merge pull request #1393 from scalamacros/topic/leaks-in-toolboxesGrzegorz Kossakowski2012-09-271-0/+26
|\ \ \ | | | | | | | | SI-6412 alleviates leaks in toolboxes, attempt #2
| * | | SI-6412 alleviates leaks in toolboxes, attempt #2Eugene Burmako2012-09-271-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns importer caches into fully weak hash maps, and also applies manual cleanup to toolboxes every time they are used. It's not enough, because reflection-mem-typecheck test is still leaking at a rate of ~100kb per typecheck, but it's much better than it was before. We'll fix the rest later, after 2.10.0-final. For more information, see https://issues.scala-lang.org/browse/SI-6412 and http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2 In comparison with https://github.com/scala/scala/commit/b403c1d, the original commit that implemented the fix, this one doesn't crash tests. The problem with the original commit was that it called tryFixup() before updating the cache, leading to stack overflows.
* | | | hardens DirectTest against missing -d settingsEugene Burmako2012-09-261-1/+1
|/ / / | | | | | | | | | | | | And also explicitly specifies -d in a test where I forgot to do that. Double checking never hurts.
* | | Merge pull request #1380 from scalamacros/ticket/6277Eugene Burmako2012-09-2612-15/+19
|\ \ \ | | | | | | | | SI-6277 fix for isXXX methods in reflection
| * | | SI-6277 fixes flags, annotations & privateWithinEugene Burmako2012-09-2612-15/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `Symbol.getFlag`, 'Symbol.hasFlag`, `Symbol.hasAllFlags`, `Symbol.annotations` and `Symbol.privateWithin` now trigger automatic initialization of symbols if they are used in a runtime reflection universe and some other conditions are met (see `Symbol.needsInitialize` for details). As the performance testing in https://github.com/scala/scala/pull/1380 shows, this commit introduces a ~2% performance regression of compilation speed. Unfortunately all known solutions to the bug at hand (A, B & C - all of those) introduce perf regressions (see the pull request linked above for details). However we're under severe time pressure, so there's no more time to explore. Therefore I suggest this is reasonable to accept this performance hit, because we've just gained 6% from removing scala.reflect.base, and even before that we were well within our performance goal for 2.10.0-final.
* | | | Merge pull request #1396 from axel22/issue/6410Josh Suereth2012-09-262-0/+11
|\ \ \ \ | |_|/ / |/| | | SI-6410 add test cases.
| * | | SI-6410 add test cases.Aleksandar Prokopec2012-09-252-0/+11
| | | |
* | | | Update check-file for SI-6344 test.Grzegorz Kossakowski2012-09-251-2/+2
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | There were some changes to value classes since pull request was tested so outdated check-file got merged. Paul confirmed that those changes are going in the right direction so all it requires is to update the check file. Review by @paulp.
* | | Merge pull request #1345 from paulp/issue/6344Grzegorz Kossakowski2012-09-252-0/+238
|\ \ \ | | | | | | | | Possible fix for SI-6344, value class generic signatures.
| * | | Fix for SI-6344, value class generic signatures.Paul Phillips2012-09-202-0/+238
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Value classes mostly erase to the erasure of the underlying type. Not everything in the checkfile looks correct, but I know from experience I can spend the rest of my life poking at erasures, so let's try to book some progress.
* | | | Revert "SI-6412 alleviates leaks in toolboxes"Grzegorz Kossakowski2012-09-251-26/+0
| | | | | | | | | | | | | | | | This reverts commit b403c1d7524ccdfc3455b5bc5d5363fdd9c82bec.
* | | | SI-6412 alleviates leaks in toolboxesEugene Burmako2012-09-241-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns importer caches into fully weak hash maps, and also applies manual cleanup to toolboxes every time they are used. It's not enough, because reflection-mem-typecheck test is still leaking at a rate of ~100kb per typecheck, but it's much better than it was before. We'll fix the rest later, after 2.10.0-final. For more information, see https://issues.scala-lang.org/browse/SI-6412 and http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
* | | | SI-6412 fixes leaks in Types.uniquesEugene Burmako2012-09-242-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the most blatant leak in reflection. There are others, but their impact is much smaller, therefore we'll fix them later, after 2.10.0-final. For more information, see https://issues.scala-lang.org/browse/SI-6412 and http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
* | | | Merge pull request #1378 from scalamacros/ticket/5918Eugene Burmako2012-09-232-0/+47
|\ \ \ \ | | | | | | | | | | SI-5918 fixes the ConstantType ugliness
| * | | | SI-5918 fixes the ConstantType uglinessEugene Burmako2012-09-232-0/+47
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Java enum values are represented with constants wrapping corresponding Symbols. To find out the underlying type of such a constant one needs to calculate sym.owner.linkedClassOfClass.tpe (where sym represents the wrapped symbol). To quote the source code, given (in java): class A { enum E { VAL1 } } - sym: the symbol of the actual enumeration value (VAL1) - .owner: the ModuleClassSymbol of the enumeration (object E) - .linkedClassOfClass: the ClassSymbol of the enumeration (class E) Back then, as far as I can guess, linkedClassOfClass was flaky and didn't work well late in the compilation pipeline. Therefore a fix to SI-1329 introduced a caching facility. Once a ConstantType representing the type of Constant(sym) was created (I guess, during typer, when linkedClassOfClass was still working), it cached the underlying type and used it in subsequent phases. *** Unfortunately this solution, being fine for enum values, broke another flavor of constants - type wrapping constants that represent classOf (for example, Constant(IntTpe) represents the classOf[Int] constant). Type-wrapping constants are special, because their type (e.g. Class[Int] in the example from the previous paragraph) changes as the compilation progresses. Before erasure it's Class[something], and after erasure it's just Class. Therefore caching types of such constants might lead to incorrect types flying around after erasure, as described in this scala-internals thread: http://groups.google.com/group/scala-internals/browse_thread/thread/45185b341aeb6a30. *** Now when the problem is clear, the question is why didn't it happen before? That's all because of another peculiarity of the compiler. Before erasure package references (e.g. in TypeRef prefixes) are represented as ThisType(sym), where sym stands for a package class symbol. After erasure such references are represented differently, e.g. java.lang package looks like TypeRef(TypeRef(TypeRef(NoPrefix, root, Nil), java, Nil), java.lang, Nil). As described in the aforementioned thread, the incorrect caching strategy employed in UniqueConstantType mixed with other caching mechanisms in compiler effectively established a non-clearable cache that goes from Type instances to types that represent their classOfs, e.g. from String to Class[String]. So if anyone tried to typecheck a classOf after erasure, he/she would get Class[String] instead of the correct Class, and compiler would crash. Right? Nope. Before erasure String is TypeRef(ThisType(java.lang), StringSymbol, Nil), and after erasure it's TypeRef(TypeRef(...), StringSymbol, Nil), as explained above. Therefore the foul cache would contain two String types: one pre-erasure going to a pre-erasure Class[String], and another one post-erasure going to a post-erasure Class. *** This shaky balance was broken when I tried to implement class tag generation with shiny Type.erasure method that Martin just exposed in the reflection API. The erasure method partially invoked the Erasure phase, and for a String it returned its post-erasure representation (with java.lang prefix represented as TypeRef, not as ThisType). And after that I used the result of erasure to build a classOf for a class tag. Since I did it in a macro, it was typer, a pre-erasure phase. Now you understand why things broke. That classOf created a Constant wrapping a post-erasure representation of String, which cached the incorrect non-erased Class[String] type for a post-erasure type, and things exploded. You can imagine my panic! The ScalaDays deadline was near, I still had to do finishing touches to implicit macros (which I actually never had time to do), and such a fundamental thing exploded. Actually I figured out the hashing problem, but in the limited time I had I failed to understand why exactly it's happening, so I introduced the dirty workaround praised in SI-5918 and moved on. *** The story doesn't end here. Some time has passed, and I learned a lot about the compiler. I independently discovered the ThisType -> TypeRef transform that erasure applies to package references and patched Type.erasure to undo it. After all, Type.erasure is a user-facing API, and users don't need to know about post-typer implementation details. You can read more about this here: http://groups.google.com/group/scala-internals/browse_thread/thread/6d3277ae21b6d581 From what we've learned above, we can see that this Type.erasure fix made the UniqueConstantType workaround unnecessary. But I didn't know that. So imagine my surprise when I tried to remove that workaround and ran the tests only to see that nothing fails. I went back in time to April when the problem first manifested, extracted a minimized crasher and tried to use it on trunk. Again, nothing crashed. And only with the help of showRaw, I finally understood that types printed as "String" can be wildly different. The rest was a piece of cake. *** The irony is that the original reason for ConstantType caching is no longer valid. linkedClassOfClass now works fine (and files/jvm/outerEnum.scala agrees with me), so we can remove the cache altogether. So why all this story about erasure and package references? Well, I don't know. I enjoyed uncovering this mystery, so I wanted to share it with you :)
* | | | Merge pull request #1379 from retronym/topic/boxing-conversionsPaul Phillips2012-09-222-0/+10
|\ \ \ \ | |/ / / |/| | | Remove BoxingConversions from the scala package.
| * | | Remove BoxingConversions from the scala package.Jason Zaugg2012-09-222-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | And add it to two test cases that rely on it. It is a remnant of the now-removed FlatArray (8cc7de74d).
* | | | A couple CRLF normalization stragglers.Paul Phillips2012-09-213-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | Now sorely needed since files with CRLF endings but an LF attribute which are checked into the repo will aggressively cause dirty git status on unix.
* | | | Merge remote-tracking branch 'paulp/topic/gitattributes' into 2.10.xPaul Phillips2012-09-20246-1927/+1927
|\ \ \ \ | |/ / / |/| | |
| * | | Normalized line endings.Paul Phillips2012-09-20246-1927/+1927
| | | | | | | | | | | | | | | | | | | | | | | | This brings all the files into line with the .gitattributes settings, which should henceforth be automatically maintained by git.
* | | | Merge pull request #1348 from scalamacros/ticket/6394Grzegorz Kossakowski2012-09-204-0/+18
|\ \ \ \ | | | | | | | | | | SI-6394 fixes macros.Context.enclosingClass
| * | | | SI-6394 fixes macros.Context.enclosingClassEugene Burmako2012-09-194-0/+18
| | |_|/ | |/| | | | | | | | | | | | | | Previously I used typer.context.enclClass, but it seems to do something completely unexpected, so I switched to manual context traversal.
* | | | Merge pull request #1360 from scalamacros/hotfix/sbtEugene Burmako2012-09-206-0/+126
|\ \ \ \ | |_|/ / |/| | | don't try to create tags w/o scala-reflect.jar
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-06 05:31:35 +0000