scala - The Scala programming language

	Commit message (Collapse)	Author	Age	Files	Lines
*	SI-8134 SI-5954 Fix companions in package object under separate comp.	Jason Zaugg	2014-01-20	1	-18/+0
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	The tests cases enclosed exhibited two failures modes under separate compilation. 1. When a synthetic companion object for a case- or implicit-class defined in a package object is called for, `Namer#ensureCompanionObject` is used to check for an explicitly defined companion before decided to create a synthetic one. This lookup of an existing companion symbol by `companionObjectOf` would locate a symbol backed by a class file which was in the scope of the enclosing package class. Furthermore, because the owner of that symbol is the package object class that has now been noted as corresponding to a source file in the current run, the class-file backed module symbol is also deemed to be from the current run. (This logic is in `Run#compiles`.) Thinking the companion module already existed, no synthetic module was created, which would lead to a crash in extension methods, which needs to add methods to it. 2. In cases when the code explicitly contains the companion pair, we still ran into problems in the backend whereby the class-file based and source-file based symbols for the module ended up in the same scope (of the package class). This tripped an assertion in `Symbol#companionModule`. We get into these problems because of the eager manner in which class-file based package object are opened in `openPackageModule`. The members of the module are copied into the scope of the enclosing package: scala> ScalaPackage.info.member(nme.List) res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462 scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List) res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462 This seems to require a two-pronged defense: 1. When we attach a pre-existing symbol for a package object symbol to the tree of its new source, unlink the "forwarder" symbols (its decls from the enclosing package class. 2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`, remove static member modules from the scope of the enclosing package object (aka `exitingFlatten(nestedModule.owner)`). This commit also removes the warnings about defining companions in package objects and converts those neg tests to pos (with -Xfatal-warnings to prove they are warning free.) Defining nested classes/objects in package objects still has a drawback: you can't shift a class from the package to the package object, or vice versa, in a binary compatible manner, because of the `package$` prefix on the flattened name of nested classes. For this reason, the `-Xlint` warning about this remains. This issue is tracked as SI-4344. However, if one heeds this warning and incrementatlly recompiles, we no longer need to run into a DoubleDefinition error (which was dressed up with a more specific diagnostic in SI-5760.) The neg test case for that bug has been converted to a pos.
*	Merge remote-tracking branch 'origin/2.10.x' into merge-210	Paul Phillips	2013-02-10	1	-6/+8
\|\ \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	* origin/2.10.x: Fix for paramaccessor alias regression. Expanded bytecode testing code. SI-5675 Discard duplicate feature warnings at a position accommodates pull request feedback term and type reftrees are now reified uniformly SI-6591 Reify and path-dependent types SI-7096 SubstSymMap copies trees before modifying their symbols SI-6961 no structural sharing in list serialization SI-6187 Make partial functions re-typable [backport] SI-6478 Fixing JavaTokenParser ident SI-7100 Fixed infinite recursion in duplicators SI-6146 More accurate prefixes for sealed subtypes. SI-5082 Cycle avoidance between case companions SI-6113 typeOf now works for type lambdas SI-5824 Fix crashes in reify with _* SI-7026: parseTree should never return a typed one SI-7070 Turn restriction on companions in pkg objs into warning Conflicts: src/compiler/scala/reflect/reify/codegen/GenSymbols.scala src/compiler/scala/tools/nsc/typechecker/PatternMatching.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/library/scala/collection/immutable/List.scala src/reflect/scala/reflect/internal/TreeInfo.scala src/reflect/scala/reflect/internal/Types.scala src/reflect/scala/reflect/internal/settings/MutableSettings.scala src/reflect/scala/reflect/runtime/Settings.scala test/files/buildmanager/t2650_1/t2650_1.check test/files/buildmanager/t2657/t2657.check test/files/neg/t3234.check test/files/run/idempotency-this.check test/files/run/macro-typecheck-macrosdisabled2.check test/files/run/showraw_tree.check test/files/run/showraw_tree_ids.check test/files/run/showraw_tree_kinds.check test/files/run/showraw_tree_types_ids.check test/files/run/showraw_tree_types_typed.check test/files/run/showraw_tree_types_untyped.check test/files/run/showraw_tree_ultimate.check test/files/run/t2886.check test/files/run/t5225_2.check test/files/run/t5374.check test/files/run/t5374.scala test/files/run/t6329_repl.check test/files/run/toolbox_typecheck_macrosdisabled2.check
\| *	SI-7070 Turn restriction on companions in pkg objs into warning	James Iry	2013-02-06	1	-5/+5
\|/ \| \| \| \| \| \| \| \| \| \| \| \|	The implementation restriction created from SI-5954 in 3ef487ecb6733bfe3c13d89780ebcfc81f9a5ea0 has two problems. 1) The problematic code works fine if compile with sbt. That means the restriction is breaking some people needlessly. 2) It's not binary compatible. To fix all that this commit changes the error into a warning and removes the setting used to get around the restriction.
*	SI-5954 Implementation restriction preventing companions in package objs	James Iry	2013-01-13	1	-0/+16
	Companion objects (and thus also case classes) in package objects caused an assert about an overloaded symbol when everything was compiled twice. It's a hairy problem that doesn't fit in 2.10.1. So this fix adds an implementation restriction. It also has a test to make sure the error messages are clean and reasonably friendly, and does not catch other things defined in package objects. The test includes a commented out test in case somebody thinks they've solved the underlying problem. A handful of tests were falling afoul of the new implementation restriction. I verified that they do in fact fail on second compile so they aren't false casualties. But they do test real things we'd like to work once the re-compile issue is fixed. So I added a -X flag to disable the implementation restriction and made all the tests accidentally clobbered by the restriction use that flag.