summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Fix for SI-6537, inaccurate unchecked warning.Paul Phillips2012-10-182-0/+17
| | | | | | | | I found a more direct expression of the unchecked logic, which should be much easier for others to verify. But the bug being fixed here is that the unchecked checking happens too early, and the sealed children of a symbol are not yet visible if it is being simultaneously compiled.
* Fix for SI-6499, regression in type inference.Paul Phillips2012-10-101-0/+3
| | | | | | | | | | | | I can't do any better than a reproduced comment: For some reason which is still a bit fuzzy, we must let Nothing through as a lower bound despite the fact that Nothing is always a lower bound. My current supposition is that the side-effecting type constraint accumulation mechanism depends on these subtype tests being performed to make forward progress when there are mutally recursive type vars. See pos/t6367 and pos/t6499 for the competing test cases.
* Merge pull request #1442 from adriaanm/ticket-6215Grzegorz Kossakowski2012-10-081-0/+1
|\ | | | | 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-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | SI-6485 stops creating extmethods for macrosEugene Burmako2012-10-083-0/+20
|/ | | | | Macros don't correspond to bytecode-level methods, therefore there's no need to undergo any transformations past typer.
* Test case for SI-6311.Paul Phillips2012-09-291-0/+5
| | | | | This covers the situation which broke in 5c5e8d4dcd, reverted in the previous commit.
* Revert "SI-4881 infer variance from formals, then result"Paul Phillips2012-09-291-31/+0
| | | | This reverts commit 5c5e8d4dcd151a6e2bf9e7c259c618b9b4eff00f.
* Moved two tests to less breaky locations.Paul Phillips2012-09-274-0/+0
| | | | | When there is a test called pos/t1107.scala and also a test called pos/t1107, it is bad.
* Additional new tests for unchecked warnings.Paul Phillips2012-09-252-0/+12
|
* 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-12 17:19:22 +0000