scala - The Scala programming language

	Commit message (Collapse)	Author	Age	Files	Lines
*	Remove deprecated Predef.error	Janek Bogucki	2016-03-26	1	-1/+1
\| \| \| \| \| \|	error was deprecated in 2.9.0 but remained to ensure compatibility with sbt. This changes follows on from an update to the latest sbt version (0.13.11).
*	Removes GenView and ParView	Jason Zaugg	2013-11-26	1	-2/+2
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	- code that used to be inherited in View is now inlined - the `view` methods on `ParIteratoa` and `ParSeq` now convert to sequential collections, and are deprecated asking the user to do this explicitly in the future. Should be largely source compatible with 2.10.x, on the assumption that the removed classes, while being public, were internal implementation details. A few tests used now-removed classes to demonstrate compiler crashes. I managed to confirm that after my decoupling, t4365 still exercises the bug: % qbin/scalac test/files/pos/t4365/.scala warning: there were 2 deprecation warning(s); re-run with -deprecation for details one warning found % scalac-hash 7b4e450 test/files/pos/t4365/.scala warning: there were 2 deprecation warning(s); re-run with -deprecation for details one warning found % scalac-hash 7b4e450~1 test/files/pos/t4365/.scala 2<&1 \| grep -i wrong error: something is wrong: cannot make sense of type application something is wrong: cannot make sense of type application something is wrong: cannot make sense of type application I didn't manage to do the same for specializes-sym-crash.scala, and instead just made it compile.
*	SI-4365 nondeterministic failure in asSeenFrom	Paul Phillips	2013-04-22	1	-0/+18
	Under some order-dependent conditions (if source files arrive in one order it happens, in the other order it does not) more than one set of type parameters are created for a given class. Previously this would lead to a crash in asSeenFrom when a type parameter had to be matched up with a type application. Now when that situation arises I compare them by name and log a dev warning if it hits. This does not risk anything undesirable happening because the wayward type parameter's owner is always the right class; it's only the class type parameters which don't include the wayward one. Since in a given type parameter list names are unique, we have enough information to salvage the search.