| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
An error suppresses all further warnings at the same position,
but multiple warnings can be heard.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/tools/nsc/doc/Settings.scala
src/compiler/scala/tools/nsc/interpreter/CompletionOutput.scala
src/compiler/scala/tools/nsc/matching/Patterns.scala
src/compiler/scala/tools/nsc/transform/UnCurry.scala
src/compiler/scala/tools/nsc/typechecker/Infer.scala
src/compiler/scala/tools/nsc/typechecker/PatternMatching.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/reflect/scala/reflect/internal/settings/MutableSettings.scala
src/reflect/scala/reflect/runtime/Settings.scala
src/swing/scala/swing/SwingActor.scala
src/swing/scala/swing/SwingWorker.scala
test/files/run/t6955.scala
|
|/
|
|
|
|
|
| |
Instead of changing warnings to errors mid-stream, at the end of
a run I check for condition "no errors, some warnings, and fatal
warnings" and then generate an error at that point. This is
necessary to test for some warnings which come from later stages.
|
|
Issue a warning about classes/objects inside package objects, no review.
|