summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Normalized line endings.Paul Phillips2012-09-201-1/+1
| | | | | | This brings all the files into line with the .gitattributes settings, which should henceforth be automatically maintained by git.
* SI-6363 removes scala.reflect.baseEugene Burmako2012-09-191-11/+15
| | | | | As the experience has shown, there's no need for a separate layer of reflection in scala-library.jar. Therefore I'm putting an end to it.
* Revert "Fix SI-6294."Grzegorz Kossakowski2012-09-171-14/+0
| | | | | | | | This reverts commit cb393fcbe35d0a871f23189d791b44be1b826ed2. Conflicts: src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
* Merge pull request #1302 from scalamacros/topic/reflectionEugene Burmako2012-09-141-8/+8
|\ | | | | cleaning up reflection
| * SI-6342 cleans up toolbox APIEugene Burmako2012-09-151-8/+8
| | | | | | | | | | | | 1) parseExpr => parse 2) runExpr => eval 3) Introduces compile(Tree): () => Any, since it has frequent uses
* | Merge pull request #1299 from namin/si-6245Paul Phillips2012-09-143-0/+17
|\ \ | |/ |/| Fix for SI-6245 with workaround for SI-2296.
| * Fix for SI-6245 with workaround for SI-2296.amin2012-09-133-0/+17
| | | | | | | | | | | | | | protected/super accessor issue: Don't subvert the creation of the standard protected accessor with the java interop accessor. For SI-2296, the compiler emits an error instead of causing an illegal access error at runtime.
* | SI-6310 AbsTypeTag => WeakTypeTagEugene Burmako2012-09-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new name for AbsTypeTag was a matter of a lengthy discussion: http://groups.google.com/group/scala-internals/browse_thread/thread/fb2007e61b505c4d I couldn't decide until having fixed SI-6323 today, which is about trying to reflect against a local class using typeOf. The problem with local classes is that they aren't pickled, so their metadata isn't preserved between Scala compilation runs. Sure, we can restore some of that metadata with Java reflection, but you get the idea. Before today typeOf of a local class created a free type, a synthetic symbol, with a bunch of synthetic children that remember the metadata, effectively creating a mini symbol table. That might be useful at time, but the problem is that this free type cannot be reflected, because the global symbol table of Scala reflection doesn't know about its mini symbol table. And then it struck me. It's not the presence of abs types (type parameters and abs type members) that differentiates arbitrary type tags from good type tags. It's the presence of types that don't map well on the runtime world - ones that can't be used to instantiate values, ones that can't be reflected. So we just need a name for these types. Phantom types are compile-time only concept, whereas our types can have partial correspondence with the runtime. "Weak types" sound more or less okish, so let's try them out.
* | Fixes SI-6259. Unable to use typeOf in super call of top-level object.Josh Suereth2012-09-131-0/+47
|/ | | | | | | | | This works around the issue of the inability to use classOf for top-level object classes by inventing a new anonymous class and instantiating it just to grab its class. Since the class is a nested type of the top-level object it'll be in the same classloader unless some kind of evil behavior is afoot. This patch should be undone if ever SI-2453 ever gets fixed, or we wind up with a direct way to grab the class of an object.
* Merge pull request #1294 from paulp/issue/6367Josh Suereth2012-09-131-0/+34
|\ | | | | Fix for SI-6367, exponential time in inference.
| * Fix for SI-6367, exponential time in inference.Paul Phillips2012-09-121-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This pathology is not new - it can be witnessed in 2.9, where compiling the test case enclosed with this ticket with -Yinfer-debug will print a line with (pinky to lips) one million type parameters. 1048576 actually, aka 2^20. But in 2.9 we were somehow getting away with creating the list, presumably by not spending much time looking at it. Somewhere between there and M1, that changed. I cut it off at the knees - don't create a list of one million upper bound constraints when 1 will suffice. It would not be too surprising if this proves to be a boon for performance.
* | Test case for a bug fixed in M7.Paul Phillips2012-09-121-0/+16
|/
* Disable test t2868Lukas Rytz2012-09-115-24/+0
| | | | it keeps failing randomly, e.g. http://scala-webapps.epfl.ch/artifacts/e3b0c7abbf637dacce7bcd7b69d5655820e8e714/buildLog.txt
* Merge pull request #1274 from retronym/ticket/6335Grzegorz Kossakowski2012-09-111-0/+25
|\ | | | | SI-6335 More precise location of the implicit class synthetic method.
| * More tests for SI-6335.Jason Zaugg2012-09-091-1/+15
| |
| * SI-6335 More precise location of the implicit class synthetic method.Jason Zaugg2012-09-091-0/+11
| | | | | | | | | | | | | | | | | | One approach would be to disallow an implicit class in a template that already has a member with the same name. But this commit doesn't do this; instead it uses `isSynthetic` to find the synthesized implicit conversion method from the potentially overloaded alternatives.
* | SI-6278 fixed: synthetic implicit def must sort with its associated implicit ↵Som Snytt2012-09-091-0/+30
|/ | | | | | | | | class Add a case to the ad-hoc (or add-hack) addSynthetics to keep the trees close. This relies on naming convention, so changes in naming of the implicit def would require an update here.
* Merge pull request #1246 from lrytz/t6274Paul Phillips2012-09-041-0/+13
|\ | | | | SI-6274 Fix owners when eta-expanding function with byName param
| * SI-6274 Fix owners when eta-expanding function with byName paramLukas Rytz2012-09-041-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | When eta-expanding a function that takes a by-name param the local definition for the corresponding argument is a function-0 val eta$1 = () => { argument-to-by-name } If there are any definitinos in the `argument-to-by-name`, the symbol owner needs to be changed to the anonymous function's symbol. To know the function symbol in eta expand, we need to type-check the function, and therefore pass the `Typer` instance to `etaExpand`.
* | Merge pull request #1217 from axel22/issue/6294Paul Phillips2012-09-041-0/+14
|\ \ | |/ |/| Fix SI-6294.
| * Fix SI-6294.Aleksandar Prokopec2012-08-301-0/+14
| |
* | Fix for SI-6034, covariant value classes.Paul Phillips2012-08-311-0/+1
| | | | | | | | | | | | | | | | My summary in the ticket was incorrect. The problem was that the class type parameters were being cloned for the method and being allowed to keep their variance. I threw in an assertion for anyone attempting to create a method type with variant type parameters, because hey, why should we allow such madness.
* | Added/fixed test files for SI-6227Martin Odersky2012-08-291-2/+0
|/
* Merge pull request #1172 from Blaisorblade/topic/deprecated-conversionJosh Suereth2012-08-231-0/+17
|\ | | | | JavaConversions: Restore source compatibility with 2.9
| * Ensure implicit conversions to concurrent map are unambiguousPaolo Giarrusso2012-08-221-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even after the parent change, implicit conversions should still convert ConcurrentHashMap to concurrent.Map and not to mutable.ConcurrentMap. I'll include the comment by axel22 which prompting this change (taken from https://github.com/scala/scala/pull/1172#issuecomment-7928285) since it is highly informative and links to pull request comments might not be very stable: << Instead of just testing an implicit conversion to ConcurrentMap, the test should call ConcurrentMap methods such as putIfAbsent (which returns an Option[T]) and replace, to see if the correct Scala concurrent map trait is being resolved. The problem is that putIfAbsent already exists on juc.ConcurrentMap so instead of triggering an implicit conversion, a type mismatch error is output anyway. And we cannot test that the correct concurrent map trait is returned using methods like map, flatMap and friends, because concurrent map traits extends mutable.Map anyway. For this reason, I recommend to add this to the test: scala> val a = new java.util.concurrent.ConcurrentHashMap[String, String]() += (("", "")) a: scala.collection.concurrent.Map[String,String] = Map("" -> "") and make sure that the returned map is concurrent.Map, not mutable.ConcurrentMap (the above += is one of the few methods in collection that has the return type this.type). >>
| * JavaConversions: Restore source compatibility with 2.9Paolo Giarrusso2012-08-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Readd an implicit conversion which was available in 2.9, the one from `java.util.concurrent.ConcurrentMap` (`juc.ConcurrentMap`) to the (now deprecated) type `scala.collection.mutable.ConcurrentMap`. This implicit conversion can also be used to convert from `juc.ConcurrentMap` to `collection.Map` and creates an ambiguity error in test/files/run/map_java_conversions.scala. To fix this, I have given lower priority to the new conversion. Moreover, update the documentation in `JavaConversions`: mark this conversion as deprecated and mention the new conversion which replaces it, converting to `scala.collection.concurrent.Map`. I discussed this issue previously with Paul Phillips on scala-language: https://groups.google.com/d/topic/scala-language/uXKRiGXb-44/discussion
* | Compilespeed improvements: Exists arguments and othersMartin Odersky2012-08-201-0/+26
|/ | | | | | | | | | | | It turns out that exists is not inlinable, even if put into List. We try to eliminate or hoist most closures passed to exists in Types. There are some other small improvements as well. -- (@gkossakowski): This commit contains also a fix to crasher prepared by @paulp. I squashed that commit and kept the test-case that came with it.
* Merge pull request #1162 from paulp/aug19-scala-graphPaul Phillips2012-08-182-0/+6
|\ | | | | Fix for community build blocker.
| * Fix for community build blocker.Paul Phillips2012-08-182-0/+6
| | | | | | | | | | | | | | | | As two character bugfixes go, this was a doozy. I will forego elaborating at length and offer generic instructions for elucidation: % git log --grep=tpeHK
* | SI-5788 correct test and symbol updateVlad Ureche2012-08-191-3/+2
|/ | | | | | Previously I thought it's fixed because I didn't include the correct testcase. Now it's the correct testcase and this prompted me to change the code a bit to make it work properly.
* Merge pull request #1093 from jsuereth/fix/SI-6208-2.10.xPaul Phillips2012-08-161-0/+4
|\ | | | | Fix SI-6208. mutable.Queue now returns mutable.Queue for collection met...
| * Fix SI-6208. mutable.Queue now returns mutable.Queue for collection methods ↵Josh Suereth2012-08-081-0/+4
| | | | | | | | rather than MutableList.
* | Merge pull request #1100 from adriaanm/ticket-6022bJosh Suereth2012-08-131-0/+20
|\ \ | | | | | | SI-6022 cleaner model of variable equality modulo <:
| * | SI-6022 cleaner model of variable equality modulo <:Adriaan Moors2012-08-091-0/+20
| | | | | | | | | | | | | | | | | | | | | a more conservative "excludes": no need to reason about types (TODO: check we don't get any spurious unreachability errors in the eclipse build, which is a good canary for this kind of thing)
* | | Merge pull request #1120 from paulp/ticket-6184-revisedJosh Suereth2012-08-111-0/+7
|\ \ \ | | | | | | | | Ticket 6184 revised
| * | | SI-6184 don't introduce dummies in checkableTypeAdriaan Moors2012-08-091-0/+7
| |/ / | | | | | | | | | | | | | | | | | | this should fix the crash in asSeenFrom that resulted from calling baseTypeSeq on a type that had an unbound type parameter in it also, simplify widenToClass
* | | SI-6201 minor fixes in key pointsEugene Burmako2012-08-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | Fixes several oversights that led to 6201. RootPackage should have been static, refactored implementation of hasSymbolWhich shouldn't have checked hasSymbol. Full discussion is here: http://groups.google.com/group/scala-internals/browse_thread/thread/9500348f273a8aa.
* | | Merge pull request #1094 from scalamacros/ticket/6204Adriaan Moors2012-08-093-0/+25
|\ \ \ | | | | | | | | fixes to existential-related reification problems
| * | | SI-6204 reifier no longer causes cyclic errorsEugene Burmako2012-08-091-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When reifying certain trees/types reifier might decide that it needs to introduce auxiliary symbols to represent non-locatable components of types For example, when reifying a refined type we need to reify the symbols that correspond to its members (aka RefinedType.decls). Since these symbols are not stored in pickles, we can't do the usual staticClass(scala.Int) stuff, and are forced to actually create corresponding symbols inside the reificode (by "create" I mean literally create, by using newXXXSymbol methods). It looks like a generally good idea to not only create those symbols naked, but to also export their type signatures and annotations. However this brings problems with type inference. Say, a type of a method A depends on a type tag. To get a type of a type tag, the compiler needs to expand the corresponding macro (when the macro is being expanded, symbol A is marked as LOCKED). While reification macro expands, it might want to reify certain symbol definitions (as explained above). If one of these definitions is a class that contains method A, we're in trouble, since reifying the corresponding ClassInfoType will eventually call A.info, which will produce a cyclic reference error, because A is LOCKED. An obvious solution is to check whether a reified symbol definition is locked. If the symbol is locked, then the reifier bails (e.g. by reifying NoType instead of the actual type signature of the symbol). Being obvious this solution is also incorrect as illustrated by SI-6204. Sure we can check whether a symbol itself is locked, but we cannot check whether or not we reify someone who refers to the locked symbol. As of such I'm telling the reifier to bail whenever it needs to reify a symbol definition for a symbol that is not yet complete. Therefore reification can no longer cause inference of method result types, which eliminates the underlying problem. This is a harsh measure, but taking into account that we have an RC planned within a week, stability trumps completeness.
| * | | SI-5756 correctly reifies local module classesEugene Burmako2012-08-092-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike module classes that are going to be pickled (which are reified as `<their module reification>.moduleClass), module classes of local modules need to be reified as symbol defs. Otherwise we get a stack overflow: 1) Local modules are deemed to be free terms, 2) All free symbols are reified together with their type signature (so that they can be a) inspected by anyone interested, b) compiled at runtime), 3) Reifying a type signature of a module involves reifying its module class, 4) Reifying a module class involves reifying a module and calling its module class, <ad infinitum> This stack overflow doesn't happen for locatable modules, because they don't need to have their type signatures reified (these signatures can later be loaded from pickles if it becomes necessary).
* | | | Merge pull request #1095 from gkossakowski/inliner-access-levelsVlad Ureche2012-08-093-0/+22
|\ \ \ \ | |_|/ / |/| | | Moved inline logic before pickler.
| * | | Moved inline logic before pickler.Grzegorz Kossakowski2012-08-093-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test case failed due to separate compilation. The problem was that we don't pickle the fact that the field was made public. Original patch by @odersky. Cleaned up by me. Changes I made: * removed stale test-case * reduced whitespace changes Supersedes #1089. Review by @odersky and @moors.
* | | | Merge pull request #1088 from adriaanm/ticket-6205Adriaan Moors2012-08-081-0/+18
|\ \ \ \ | | | | | | | | | | SI-6205 make pt fully defined before inferTypedPattern
| * | | | SI-6205 make pt fully defined before inferTypedPatternAdriaan Moors2012-08-081-0/+18
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | refines my fix for SI-2038 (#981) by making pt fully defined before calling inferTypedPattern, instead of making the result of inferTypedPattern fully defined I finally realized my mistake by diffing the -Ytyper-debug output of compiling the variants with: ``` x match {case Holder(k: A[kt]) => (k: A[kt])} ``` and ``` (x: Any) match {case Holder(k: A[kt]) => (k: A[kt])} ```
* | | | Merge pull request #1064 from adriaanm/ticket-6145Adriaan Moors2012-08-081-0/+11
|\ \ \ \ | |/ / / |/| | | SI-6145 lax typing of args to synthetic case-labels
| * | | SI-6145 lax typing of args to synthetic case-labelsAdriaan Moors2012-08-071-0/+11
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use wildcard for the expected type of the arguments of a jump to a label synthesized by the pattern matcher... except during erasure: we must take the expected type into account as it drives the insertion of casts! It's ok since we're typing the translation of well-typed code. The only "type errors" we catch are skolem mismatches. (after erasure the existential types that before caused problems have disappeared.) It's necessary to balance GADT magic, SI-6145, CPS type-driven transforms and other existential trickiness. I've exhausted all other semi-clean approaches I could think of: - the right thing to do -- packing existential types -- runs into limitations in subtyping existential types, - casting breaks SI-6145 (and it's an unnecessary cast at run time), - not casting breaks GADT typing as it requires sneaking ill-typed trees past typer
* | | Merge pull request #1075 from adriaanm/ticket-6040Adriaan Moors2012-08-081-0/+3
|\ \ \ | | | | | | | | SI-6040 error on unauthorized extension Dynamic
| * | | SI-6040 error on unauthorized extension DynamicAdriaan Moors2012-08-081-0/+3
| | | | | | | | | | | | | | | | authorization is easy to get: `import language.dynamics`
* | | | SI-6186 TypeTags no longer supported in macrosEugene Burmako2012-08-071-2/+2
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original idea was to support both both TypeTags and ConcreteTypeTags as context bounds on macro implementations. Back then TypeTags were the implied default flavor of type tags. Basically because "TypeTag" is shorter than "ConcreteTypeTag" everyone jumped onto them and used them everywhere. That led to problems, because at that time TypeTags could reify unresolved type parameters ("unresolved" = not having TypeTag annotations for them). This led to a series of creepy errors, when one forgets to add a context bound in the middle of a chain of methods that all pass a type tag around, and then suddenly all the tags turn into pumpkins (because that unlucky method just reifies TypeRef(NoPrefix, <type parameter symbol>, Nil and passes it down the chain). Hence we decided to rename ConcreteTypeTag => TypeTag & TypeTag => AbsTypeTag, which makes a lot of sense from a reflection point of view. Unfortunately this broke macros (in a sense), because now everyone writes TypeTag context bounds on macro implementations, which breaks in trivial situations like: "def foo[T](x: T) = identity_macro(x)" (the type of x is not concrete, so macro expansion will emit an error when trying to materialize the corresponding TypeTag). Now we restore the broken balance by banning TypeTag from macro impls. This forces anyone to use AbsTypeTags, and if someone wants to check the input for presence of abstract types, it's possible to do that manually.
* | | Merge pull request #1063 from VladUreche/issue/5788-quickJosh Suereth2012-08-071-0/+4
|\ \ \ | |/ / |/| | SI-5788 Tailcalls LabelDefs correctly duplicated
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-19 22:41:37 +0000