summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* | SI-7458 Pres. compiler must not observe trees in silent modeJason Zaugg2013-12-021-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | Otherwise we can think that `+` in `1 + BigInt(2)` refers to a method in `Int`. In general, this protects the IDE from observing results from "exploratory" typing which is discarded as the compiler backtracks to another possibility. This protection subsumes the condition that checked for overloaded types: presentation/t7458 now passes without this.
* | SI-7548 askTypeAt returns the same type whether the source was fully or ↵Mirco Dotta2013-12-021-9/+14
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | targeted type-checked When asking for targeted typecheck, the located tree may have overloaded types is the source isn't yet fully typechecked (e.g., a select tree for an overloaded method). This is problematic as it can lead to unknown 'hovers', broken hyperlinking that suddenly starts working, unresolved ScalaDoc comments, and similar, in the Scala IDE. With this commit we are hardening the contract of `askTypeAt` to return the same type whether the file was fully type-checked or targeted type-checked. This is done by preventing the typechecker to stop too early if the `located` tree has an overloaded type. Furthermore, I'm assuming that if `located.tpe` is of type `OverloadedType`, by letting the compiler carry-on the typechecking, the `located.tpe` will eventually be resolved to a non-overloaded type. Said otherwise, I expect the targeted typechecking will always terminate (if my reasoning isn't sound, please say so). The test provided with this commit demonstrates the new behavior (the position used to execute the test is resolved to the `foo` method's call). In fact, before this commit, executing the test returned the following: (x: Int, y: String)Unit <and> (x: String)Unit <and> (x: Int)Unit Showing that the tree's type is an overloaded type. The ambiguity is fixed by this commit, and in fact the test's output is now: (x: Int)Unit
* Merge pull request #3180 from xeno-by/topic/toolbox-rangeposJason Zaugg2013-11-261-2/+7
|\ | | | | teaches toolbox about -Yrangepos
| * [nomaster] teaches toolbox about -YrangeposEugene Burmako2013-11-221-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | Unlike in master, in 2.10.x enabling -Yrangepos requires instantiating Global with mixed in RangePositions trait. Same story for toolboxes. Just setting Yrangepos is not enough - one needs to mix in RangePositions into ToolboxGlobal. I didn’t know that back then, so now I’m fixing the oversight. The commit is marked as [nomaster], because -Yrangepos doesn’t need special treatment in master.
* | SI-8005 Fixes NoPositon error for updateDynamic callsSimon Schaefer2013-11-261-1/+3
| | | | | | | | | | | | | | | | Previously there occurred a NoPosition error when one asks for position information in the AST because no positions were set to the trees created during the transformation for updateDynamic calls. This commit applies range positions to the trees in order to being able to highlight them inside of the scala-ide.
* | SI-8004 Resolve NoPosition error for applyDynamicNamed method callSimon Schaefer2013-11-261-2/+7
| | | | | | | | | | | | | | | | | | Previously, there were no positions created for the tuples that are generated while doing the transformation for an applyDynamicNamed call. This led to an NoPosition error in scalac when one tries to show position information in the AST. Furthermore, this simplifies semantic highlighting in the scala-ide because no position information for color ranges have to be created anymore.
* | SI-7463,SI-8003 Correct wrong position for {select,apply}Dynamic callsSimon Schaefer2013-11-261-1/+4
|/ | | | | | | | | | | | The new positions are range positions that directly refer to the beginning and the end of the method calls in the sources instead of simply point to the beginning of the expression. This allows the scala-ide to semantically highlight select- and applyDynamic method calls, because it has only to traverse the tree and apply the color ranges to the given position ranges. This also fixes the position marker of an error messages related to a wrong Dynamic method signature.
* Merge pull request #3166 from skyluc/issue/completion-import-object-7280-210Jason Zaugg2013-11-225-37/+100
|\ | | | | Backport of
| * [nomaster] SI-7280 Scope completion not returning members provided by importsLuc Bourlier2013-11-211-25/+40
| | | | | | | | | | | | | | | | | | Updates localeContext() to return the best context possible when there are none directly associated with the given position. It happens when an expression cannot be successfully typed, as no precise ContextTree covers the expression location, or if the position is not inside any expression. Adds corresponding tests (cherry picked from commit 3028327e2a2b553b12ee45519413515c8aa0865f)
| * [nomaster] Test infrastructure for scope completionJason Zaugg2013-11-214-12/+60
| | | | | | | | | | | | Adds a new marker /*_*/ to trigger scope completion test. Original type completion test oracles update for the tweaked output (cherry picked from commit 9c7c66ff7907e3ab814f0f4375eeaf6cdd230d5e)
* | SI-7915 Corrected range positions created during default args expansionMirco Dotta2013-11-191-3/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tree created during expansion of default arguments contained trees with the wrong type of positions. Let's discuss this with an example. Below is the tree generated for the `foo` method in the test class included in this commit. Before this commit: ``` [54:94]def foo(): [58]Unit = <70:90>{ [70:79]<artifact> val qual$1: [70]Bar = [70:79][70:79][70:79]new [74:77]Bar(); [80]<artifact> val x$1: [80]Int = [80]qual$1.bar$default$1; <70:90><70:83>qual$1.bar([80]x$1) } ``` Now: ``` [54:99]def foo(): [58]Unit = <70:95>{ <70:84><artifact> val qual$1: [70]Bar = [70:84][70:84][70:84]new [74:77]Bar(); [85]<artifact> val x$1: [85]Int = [85]qual$1.bar$default$1; <70:95>[84:88]qual$1.bar([85]x$1) } ``` Here are the list of changes: * The synthetic `qual$1` has a transparent position, instead of a range position. * The new Select tree (i.e., `qual$1.bar`) should always have a range position, because `selected` (i.e., the called method) is always visible in the source (in fact, this is the whole point of the fix, we need a range position or hyperlinking request from the Scala IDE won't work). * The Block that contains the expanded default arguments is forced to have a transparent position, as it never exist in the original source. The tricky part of the fix is the position assigned to the new Select tree, which needs to respect the range position's invariants. In the specific case, we ought to make sure that range positions don't overlap. Therefore, the position assigned to the new Select tree is computed by intersecting the original Select position (i.e., `baseFun`'s position) and the original qualifier's position (i.e., `qual`'s position). If you take a closer look at the range positions assigned in the tree after this commit, you'll notice that the range position of the `qual$1`'s rhs (i.e., [70:84]), and `qual$1.bar` (i.e., [84:88]) might seem to overlap, because the former ends where the latter begins. However, this not the case because of the range position's invariant 2, which states: > Invariant 2: in a range position, start <= point < end Hence, the above two positions aren't overlapping as far as the compiler is concerned. One additional aspect (that may look like a detail) is that we make sure to never generate a position such that its start is after its end. This is why we take the position with the smallest end point. Furthermore, calling `withStart` would turn any position in a range position, which isn't desiderable in general (and, even worse, this can lead to generation of invalid positions - bad offsets - if the computation is performed on offset positions). Hence, the position's computation is only performed when both `baseFun` and `qual` positions are range positions. Indeed, I expect this to be always the case if the compiler is started with -Yrangepos. (cherry picked from commit 3009a525b58a4c7865ff524899b85518884ee5f7)
* Merge pull request #3109 from adriaanm/faster-build-2.10Adriaan Moors2013-11-081-0/+20
|\ | | | | Faster build 2.10
| * IDE needs swing/actors/continuationsAdriaan Moors2013-11-081-0/+5
| |
| * Allow publishing only core (pr validation)Adriaan Moors2013-11-061-0/+15
| |
* | Merge pull request #3110 from xeno-by/topic/7776-backportEugene Burmako2013-11-081-2/+6
|\ \ | | | | | | [backport] SI-7776 post-erasure signature clashes are now macro-aware
| * | [backport] SI-7776 post-erasure signature clashes are now macro-awareEugene Burmako2013-11-081-2/+6
| | | | | | | | | | | | | | | | | | | | | "double definition: macro this and method that have same type after erasure" This error doesn't make sense when macros are involved, because macros expand at compile-time, where we're not affected by erasure. Moreover, macros produce no bytecode, which means that we're safe from VerifyErrors.
* | | Merge pull request #3105 from retronym/ticket/completionGrzegorz Kossakowski2013-11-081-2/+7
|\ \ \ | |/ / |/| | Fix completion after application with implicit arguments
| * | Fix completion after application with implicit argumentsJason Zaugg2013-11-061-2/+7
| |/ | | | | | | | | | | | | | | | | | | | | | | `List(1, 2, 3).map(f).<ctrl-space>` now works; before the tree had the type `(bf: CanBuildFrom[...]):...` and did not contribute completions from the result type. This commit checks if the tree has an implicit method type, and typechecks it as a qualifier. That is enough to get to `adaptToImplicitMethod` in the type checker, infer the implicit arguments, and compute the final result type accordingly.
* / SI-6546 InnerClasses attribute refers to absent classPaul Phillips2013-11-042-2/+10
|/ | | | | | | | | | | | | | | | | | | | | | At issue is that the optimizer would eliminate closure classes completely, then neglect to eliminate those classes from the container's InnerClasses attribute. This breaks tooling which expects those entries to correspond to real classes. The code change is essentially mgarcia's - I minimized it and put the caches in perRunCaches, and added the test case which verifies that after being compiled under -optimise, there are no inner classes. Before/after: 7,8d6 < InnerClasses: < public final #22; //class A_1$$anonfun$f$1 37,45c35,40 < #21 = Utf8 A_1$$anonfun$f$1 < #22 = Class #21 // A_1$$anonfun$f$1 < #23 = Utf8 Code --- > #21 = Utf8 Code
* Merge pull request #3072 from retronym/backport/7519Adriaan Moors2013-10-241-2/+3
|\ | | | | [nomaster] SI-7519 Less brutal attribute resetting in adapt fallback
| * [nomaster] SI-7519 Less brutal attribute resetting in adapt fallbackJason Zaugg2013-10-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Prefers `resetLocalAttrs` over `resetAllAttrs`. The latter loses track of which enclosing class of the given name is referenced by a `This` node which prefixes the an applied implicit view. The code that `resetAllAttrs` originally landed in: https://github.com/scala/scala/commit/d4c63b#L6R804 Cherry picked from 433880e91cba9e1e926e9fcbf04ecd4aeb1d73eb Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
* | Merge pull request #3053 from som-snytt/issue/6026-AFCL-findresourceJason Zaugg2013-10-231-1/+15
|\ \ | | | | | | [nomaster] SI-6026 backport getResource bug fix
| * | [nomaster] SI-6026 backport getResource bug fixSom Snytt2013-10-181-1/+15
| | | | | | | | | | | | | | | Submitted to master under SI-4936, this fix allows :javap to work when tools.jar is discovered by REPL.
* | | Merge pull request #3052 from som-snytt/issue/6026-javap-loadingJason Zaugg2013-10-231-12/+16
|\ \ \ | |_|/ |/| | SI-6026 REPL checks for javap before tools.jar
| * | SI-6026 REPL checks for javap before tools.jarSom Snytt2013-10-181-12/+16
| |/ | | | | | | | | | | If javap is already available, don't go hunting for tools.jar This avoids the getResource bug in AbstractFileClassLoader.
* / SI-7295 Fix windows batch file with args containing parenthesesJason Zaugg2013-10-211-7/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In command scripts, substitution of `FOO` in `if cond ( %FOO% )` happens *before* the condition is evaluated. One can use delayed expansion with `if cond (!FOO!)` to get a saner behaviour. Or, as I ended up doing here, use a goto in the body of the if rather than referring directly to variables there. Here's a cut down version to demonstrate the old problem: C:\Users\IEUser>type test.cmd @echo off setlocal enableextensions enabledelayedexpansion if [%~1]==[-toolcp] ( set CP=%~2 shift shift ) echo -toolcp %CP% echo %~1 %~2 C:\Users\IEUser>test.cmd a b -toolcp a b C:\Users\IEUser>test.cmd -toolcp "c:\program files" a b -toolcp c:\program files a b C:\Users\IEUser>test.cmd -toolcp "c:\program files" "a()b" "c()d" -toolcp c:\program files a()b c()d C:\Users\IEUser>test.cmd "a()b" "c()d" d was unexpected at this time. I don't understand exactly why the parentheses only mess things up in this situation. But regardless, lets find another way. My first attempt to fix this was based on the suggestion in the ticket. But, as shown below, this fails to capture the -toolcp. C:\Users\IEUser>type test.cmd @echo off setlocal enableextensions enabledelayedexpansion if [%~1]==[-toolcp] ( set CP=!2! shift shift ) echo -toolcp %CP% echo %~1 %~2 C:\Users\IEUser>test.cmd "a()b" "c()d" -toolcp a()b c()d C:\Users\IEUser>test.cmd -toolcp "c:\program files" "a()b" "c()d" -toolcp a()b c()d Last stop was the goto you'll find in this patch. With this patch applied, I tested on Windows 8 with the following: C:\Users\IEUser>type Desktop\temp.cmd ::#! @echo off call scala %0 %* goto :eof ::!# println("hello, world") println(argv.toList) C:\Users\IEUser>scala Desktop\temp.cmd "foo(bar)baz" "java" -Xmx256M -Xms32M -Dscala.home="C:\PROGRA~3\scala\bin\.." -Denv.emacs="" -Dscala.usejavacp=true -cp "..." scala.tools.nsc.MainGenericRunner Desktop\temp.cmd "foo(bar)baz" hello, world List(foo(bar)baz) C:\Users\IEUser>scala -toolcp "c:\program files" Desktop\temp.cmd "foo(bar)baz" "java" -Xmx256M -Xms32M -Dscala.home="C:\PROGRA~3\scala\bin\.." -Denv.emacs="" -Dscala.usejavacp=true -cp "...;c:\program files" scala.tools.nsc.MainGenericRunner -toolcp "c:\program files" Desktop\temp.cmd "foo(bar)baz" hello, world List(foo(bar)baz)
* Merge pull request #2985 from retronym/ticket/7783Jason Zaugg2013-10-031-1/+5
|\ | | | | Don't issue deprecation warnings for inferred TypeTrees
| * SI-7783 Don't issue deprecation warnings for inferred TypeTreesJason Zaugg2013-09-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Deprecation checks in RefChecks were looking into all TypeTrees to find references to deprecated type aliases. However, when the compiler infers a type argument or type of a member it creates a TypeTree (with a null original) that was also leading to warnings. I ran into this problem often when upgrading a build from SBT 0.12 to 0.13: a plugin I was using used the deprecated type alias, and I suffered transitively when I used methods from its API. This commit disables the checks for inferred TypeTree-s.
* | Merge remote-tracking branch 'origin/2.10.3' into merge/2.10.3-to-2.10.xJason Zaugg2013-09-241-7/+4
|\ \ | |/ |/|
| * SI-7861 Don't execute internal callbacks on the user ExecutorJason Zaugg2013-09-211-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Callbacks internal to the implementation of Futures should be executed with the `InternalCallbackExecutor`, rather than the user supplied `Executor`. In a refactoring da54f34a6, `recoverWith` and `flatMap` no longer played by these rules. This was noticed by a persnickety test in Play. Before this patch, the enclosed test outputs: % scala-hash v2.10.3-RC2 test/files/run/future-flatmap-exec-count.scala mapping execute() flatmapping execute() execute() recovering execute() execute()
* | Merge pull request #2919 from retronym/ticket/7815Jason Zaugg2013-09-231-2/+2
|\ \ | |/ |/| SI-7815 Dealias before deeming method type as dependent
| * SI-7815 Dealias before deeming method type as dependentJason Zaugg2013-09-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | To enable eta-expansion of method types seen from a prefix that renders the result type as independent from the parameter symbols. The enclosed test shows that we dealias types before checking dependence, and that we do this deeply (e.g. type arguments are also dealised.) An existing test, neg/error_dependentMethodTpeConversionToFunction, confirms that bona-fide dependent methods are still prohibited from eta expansion.
* | Merge pull request #2923 from retronym/ticket/7825Grzegorz Kossakowski2013-09-112-2/+5
|\ \ | | | | | | SI-7825 Consider DEFAULTMETHOD when refchecking concreteness
| * | SI-7825 Consider DEFAULTMETHOD when refchecking concretenessJason Zaugg2013-09-102-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A class should not be required to implement a Java default method. This commit uses `isDeferredNotDefault` in place of `isDeferred` when finding unimplemented methods. The test itself does not depend on Java 8 as we use scalac's Java source parser to set things up.
* | | Merge pull request #2916 from retronym/ticket/7818Jason Zaugg2013-09-101-1/+6
|\ \ \ | | | | | | | | SI-7818 Cast our way out of extended existential angst
| * | | SI-7818 Cast our way out of extended existential angstJason Zaugg2013-09-061-1/+6
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `substituteSymbols` is not sophisticated enough to operate on `TypeSkolem`-s which are based on one of the "from" symbols. The pertinant usage of `substituteSymbols` for this bug in in `Extender`. Recapping on that transform: // orig class C[T](...) extends AnyVal { def foo[U] = <rhs> } // transform class C[T] extends AnyVal { ... } object C { def foo$extension[T', U'] = <rhs'> } Where `<rhs'>` has been subtituted with, among other things, `[T, U] ~> [T', U']`. In this case our expected type contains a new type parameter (of the extension method), whereas the type of the RHS contains an existential skolem still pinned to the corresponding class type parameter. tree.tpe = Observable1#7037[_$1#12344] <_$1#12344>.info = <: T#7040 pt = Observable1#7037[T#15644] The limitation of substution is lamented in the comments of `adaptMismatchedSkolems`, which faces the harder version of the issue where the skolems are in the expected type. But, we're in the "easy" case with the skolems in the tree's type; we can cast our way out of the problem. See also f335e447 / ed915c54.
* | | Merge pull request #2922 from huitseeker/issue/7767Jason Zaugg2013-09-101-0/+2
|\ \ \ | | | | | | | | SI-7767 avoid rejecting Scaladoc comments in early initializers
| * | | SI-7767 avoid rejecting Scaladoc comments in early initializersFrançois Garillot2013-09-091-0/+2
| | |/ | |/| | | | | | | review by @retronym
* | | Merge pull request #2866 from retronym/ticket/7269Jason Zaugg2013-09-092-3/+5
|\ \ \ | | | | | | | | SI-7269 Rework MapLike#retains to account for desugaring change
| * | | SI-7269 Rework MapLike#retains to account for desugaring changeJason Zaugg2013-08-292-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `MapLike#retains` contains a for-comprehension that relied on the strict `filter` by its generator. You can't, in general, iterate a mutable map and remove items in the same pass. Here's the history of the desugaring of: def retain[A, B](thiz: mutable.Map[A, B])(p: (A, B) => Boolean): thiz.type = { thiz.foreach { case (k, v) => if (p(k, v)) thiz -= k } Before regression (c82ecabad6~1): thiz.filter(((check$ifrefutable$1) => check$ifrefutable$1: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => true case _ => false })).withFilter(((x$1) => x$1: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang })).foreach(((x$2) => x$2: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k) })); After regression (c82ecabad6, which incorrectly assumed in the parser that no filter is required for isInstanceOf[Tuple2]) thiz.withFilter(((x$1) => x$1: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang })).foreach(((x$2) => x$2: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k) })); After the reversion of c82ecabad6, v2.10.2 This is also after 365bb2b4e, which uses `withFilter` rather than `filter`. thiz.withFilter(((check$q$1) => check$ifrefutable$1: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => true case _ => false })).withFilter(((x$1) => x$1: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang })).foreach(((x$2) => x$2: @scala.unchecked match { case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k) })); This commit does the same as `SetLike#retains`, and converts the map to an immutable list before the rest of the operation.
* | | | Merge pull request #2911 from retronym/ticket/7814Jason Zaugg2013-09-091-35/+31
|\ \ \ \ | |_|/ / |/| | | SI-7814 Avoid init cycle between Predef, `package`, ScalaRuntime
| * | | SI-7814 Updates the instrumented version of ScalaRuntime.Jason Zaugg2013-09-051-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some tests for specialization use a modified version of the standard library that count boxing, array lookups etc. These sources are updated manually with the script: % test/instrumented/mkinstrumented.sh build Looks that that wasn't done for a while, though. This commit brings it up to date, and adjusts a few braces in ScalaRuntime.scala so the patch srt.scala (used by that script) is shorter. We should really avoid checking in the products of that script and run it as part of the build, or, better, use the bytecode instrumentation framework instead of a modified standard library. But I have to leave that for another day.
| * | | SI-7814 Avoid init cycle between Predef, `package`, ScalaRuntimeJason Zaugg2013-09-051-11/+3
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not every application will force these in a single thread; we have to do our best to avoid cycles between them. The enclosed test was failing every time before the change. This commit breaks the cycle by avoiding computing `tupleNames` in the constructor of `ScalaRuntime`. The new version has the added benefit of including specialized tuple subclasses, which is verified with a unit test for `isTuple`. Are there more of these lurking? It seems likely. I'm more than a little concerned about the way the `ControlThrowable` fires up `scala.SystemProperties` to check whether or not to suppress stack traces; there is already an ugly hack in place: object NoStackTrace { final def noSuppression = _noSuppression // two-stage init to make checkinit happy, // since sys.SystemProperties.noTraceSupression.value // calls back into NoStackTrace.noSuppression final private var _noSuppression = false _noSuppression = sys.SystemProperties.noTraceSupression.value }
* | | Merge pull request #2895 from som-snytt/issue/7652-tools-jar-backportGrzegorz Kossakowski2013-09-082-13/+24
|\ \ \ | |/ / |/| | SI-7652 REPL tools jar backport
| * | [nomaster] SI-7652 REPL extended quest for toolsSom Snytt2013-08-291-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Javap tries harder and fails louder when looking for tools.jar This is a backport of the method as it was first coded for partest. If JAVA_HOME is wrong, it will either fail with a message or succeed after rooting about. ``` apm@mara:~/tmp/q$ JAVA_HOME=$JAVA7_HOME JAVACMD='/usr/lib/jvm/java-6-openjdk-amd64/bin/java' /home/apm/projects/snytt/build/pack/bin/scala Welcome to Scala version 2.10.3-20130829-123337-59d6568daa (OpenJDK 64-Bit Server VM, Java 1.6.0_27). Type in expressions to have them evaluated. Type :help for more information. scala> :javap :javap [-lcsvp] [path1 path2 ...] scala> :javap java.lang.Object Failed: Could not load javap tool. Check that JAVA_HOME is correct. apm@mara:~/tmp/q$ JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64/jre JAVACMD='/usr/lib/jvm/java-6-openjdk-amd64/bin/java' /home/apm/projects/snytt/build/pack/bin/scala Welcome to Scala version 2.10.3-20130829-123337-59d6568daa (OpenJDK 64-Bit Server VM, Java 1.6.0_27). Type in expressions to have them evaluated. Type :help for more information. scala> scala> :javap :javap [-lcsvp] [path1 path2 ...] scala> :javap java.lang.Object Compiled from "Object.java" ```
| * | [nomaster] SI-7652 Bad tools fails loudlySom Snytt2013-08-291-1/+1
| | | | | | | | | | | | | | | | | | A brief message is all that's required to alleviate the look of consternation on the face of your user.
* | | Merge pull request #2888 from xeno-by/topic/typed-annotatedJason Zaugg2013-09-041-1/+1
|\ \ \ | | | | | | | | typedAnnotated no longer emits nulls
| * | | typedAnnotated no longer emits nullsEugene Burmako2013-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Adds a null-check in original synthesis for the result of typedAnnotated. Previously it was possible for the aforementioned result to look like TypeTree(<tpe>) setOriginal Annotated(..., null). Not anymore.
* | | | Merge pull request #2901 from gkossakowski/backport-uniques-memory-fixGrzegorz Kossakowski2013-09-043-54/+416
|\ \ \ \ | | | | | | | | | | Backport #2605 to 2.10.x: SI-7149 Use a WeakHashSet for type uniqueness
| * | | | Modify perRunCaches to not leak WeakReferencesJames Iry2013-09-031-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | perRunCaches was using a HashMap of WeakReferences which meant it would accumulate WeakReferences over time. This commit uses a WeakHashSet instead so that the references are cleaned up.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 01:51:05 +0000