summaryrefslogtreecommitdiff
path: root/test/files/run/t3887.scala
Commit message (Collapse)AuthorAgeFilesLines
* Cull extraneous whitespace.Paul Phillips2013-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | | One last flurry with the broom before I leave you slobs to code in your own filth. Eliminated all the trailing whitespace I could manage, with special prejudice reserved for the test cases which depended on the preservation of trailing whitespace. Was reminded I cannot figure out how to eliminate the trailing space on the "scala> " prompt in repl transcripts. At least reduced the number of such empty prompts by trimming transcript code on the way in. Routed ConsoleReporter's "printMessage" through a trailing whitespace stripping method which might help futureproof against the future of whitespace diseases. Deleted the up-to-40 lines of trailing whitespace found in various library files. It seems like only yesterday we performed whitespace surgery on the whole repo. Clearly it doesn't stick very well. I suggest it would work better to enforce a few requirements on the way in.
* Begone t1737...Hubert Plociniczak2011-11-021-1/+1
|
* Unreverting r23174. No review.Paul Phillips2010-10-061-0/+16
|
* Reverts r23174, which I believe will bring the ...Paul Phillips2010-10-041-16/+0
| | | | | | Reverts r23174, which I believe will bring the build back to life. It only chokes under -optimise. No review.
* Work on the pattern matcher.Paul Phillips2010-10-031-0/+16
patches for #3887 and #3888, but I determined that I could achieve the same effect by deleting a bunch of code, so I did. This left only a few lines in TransMatch, so I eliminated it, which led me to remember that many places still reference non-existent phase transmatch, so those were updated. Notes: * This swaps equality tests on stable identifier patterns. They have never conformed to the spec (as noted long ago in ticket #785) which says "The pattern matches any value v such that r == v" whereas until now the test being performed was v == r. * An issue was introduced with specialization in that the implementation of "isTupleType" in Definitions relied upon sym == TupleClass(elems.length). This test is untrue for specialized tuples, causing mysterious behavior because only some tuples are specialized. There is now "isTupleTypeOrSubtype" although it seems likely the former implementation is unnecessary. The issue is sidestepped if one uses "getProductArgs" to retrieve the element types because it sifts through the base types for the Product symbol. Closes #3887 and #3888, review by dmharrah.