summaryrefslogtreecommitdiff
path: root/test/files/run/t6989
Commit message (Collapse)AuthorAgeFilesLines
* some renamingsEugene Burmako2014-02-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It’s almost 1am, so I’m only scratching the surface, mechanistically applying the renames that I’ve written down in my notebook: * typeSignature => info * declarations => decls * nme/tpnme => termNames/typeNames * paramss => paramLists * allOverriddenSymbols => overrides Some explanation is in order so that I don’t get crucified :) 1) No information loss happens when abbreviating `typeSignature` and `declarations`. We already have contractions in a number of our public APIs (e.g. `typeParams`), and I think it’s fine to shorten words as long as people can understand the shortened versions without a background in scalac. 2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would be thoughtful of us to provide newcomers with better names. To offset the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor` to `Symbol.isConstructor`, which covers the most popular use case for nme’s. 3) I also agree that putting `paramss` is a lot to ask of our users. The double-“s” convention is very neat, but let’s admit that it’s just weird for the newcomers. I think `paramLists` is a good compromise here. 4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful and a shorter name would be a much better fit for the public API.
* sane semantics for Symbols.companionSymbolEugene Burmako2014-02-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While playing with tests for Type.companionType, I figured out that companionSymbol isn’t what it seems to be: scala> ScalaPackage.companionSymbol res5: $r.intp.global.Symbol = <none> scala> ScalaPackageClass.companionSymbol res6: $r.intp.global.Symbol = package scala Or even funnier observation: scala> class C; object C defined class C defined object C scala> val classC = typeOf[C].typeSymbol classC: $r.intp.global.Symbol = class C scala> val moduleC = classC.companionSymbol moduleC: $r.intp.global.Symbol = object C scala> classC.companionSymbol == moduleC res0: Boolean = true scala> moduleC.companionSymbol == classC res1: Boolean = true scala> moduleC.moduleClass.companionSymbol == moduleC res2: Boolean = true Of course, I rushed to clean this up, so that `companionSymbol` only returns something other than NoSymbol if the target has a companion in the common sense, not wrt the internal “class with the same name in the same package” convention of scalac, and that `companionSymbol` for module classes is a class, not a source module. Unfortunately it’s not that easy, because api.Symbol#companionSymbol has the same name as internal.Symbol#companionSymbol, so we can’t change the behavior of the former without changing the behavior of the latter. Therefore I deprecated api.Symbol#companionSymbol and introduced a replacement called api.Symbol#companion with sane semantics.
* [backport #1727] SI-7359 cyclic nested java classAdriaan Moors2013-05-161-0/+2
| | | | | | | | | | | | | | | | | | | The original commit message (from 54a84a36d5): SI-6548 reflection correctly enters jinners When completing Java classes, runtime reflection enumerates their fields, methods, constructors and inner classes, loads them and enters them into either the instance part (ClassSymbol) or the static part (ModuleSymbol). However unlike fields, methods and constructors, inner classes don't need to be entered explicitly - they are entered implicitly when being loaded. This patch fixes the double-enter problem, make sure that enter-on-load uses the correct owner, and also hardens jclassAsScala against double enters that can occur in a different scenario.
* introduces an exhaustive java-to-scala testEugene Burmako2013-02-052-13/+66
| | | | | | | | | | Originally composed to accommodate pull request feedback, this test has uncovered a handful of bugs in FromJavaClassCompleter, namely: * SI-7071 non-public ctors get lost * SI-7072 inner classes are read incorrectly I'm leaving the incorrect results of FromJavaClassCompleters in the check file, so that we get notified when something changes there.
* SI-6989 privateWithin is now populated in reflectEugene Burmako2013-02-042-0/+30
Runtime reflection in JavaMirrors previously forgot to fill in privateWithin when importing Java reflection artifacts. Now this is fixed.