Do not allow named self in objects

[smarter]

object A { foo: Bla => } was already prohibited, we extend this
restriction to object A { foo => }, the latter is not really useful
and it currently causes a MatchError in SymDenotation#sourceModule when
unpickling.

[odersky]

I think we should keep allowing it. The main use for named self is that you don't have to remember the qualified this syntax to access an outer this. It's inconsistent to allow this for classes but not for modules.

[smarter]

You can always refer to modules via their name so the named self doesn't seem to buy you much, but OK, I'll try to find another fix then.

[odersky]

You can always refer to modules via their name so the named self doesn't seem to buy you much, but OK, I'll try to find another fix then.

Good point! I withdraw my objection. We can drop the self type for modules then.

[odersky]

Nice if a fix leads to a LOC reduction.

[liufengyun]

The benchmarks for stdlib fail after this merge:

# Warmup Iteration   1: -- [E013] Syntax Error: /data/workspace/bench/tests/scala-library/Traversable.scala:92:61
92 |object Traversable extends TraversableFactory[Traversable] { self =>
   |                                                             ^^^^
   |                                       objects must not have a self type

longer explanation available when compiling with `-explain`
-- Error: /data/workspace/bench/tests/scala-library/immutable/Range.scala:156:4
156 |    validateMaxLength()
    |    ^^^^^^^^^^^^^^^^^
    |method validateMaxLength in class Range cannot be accessed as a member of Range(Range_this) from class CombinationsItr.
    | This location is in code that was inlined at /data/workspace/bench/tests/scala-library/SeqLike.scala:223
two errors found

Need to investigate more:

https://github.com/liufengyun/bench/blob/master/tests/scala-library/Traversable.scala#L92

[smarter]

This was fixed in the scala2-library submodule, you can just cherry-pick the fix: lampepfl/scala@e588767...723f222

[Blaisorblade]

So this is a new change for Scalafix to handle? I'm not sure removing such things is worth the trouble.

[odersky]

After having played with it I now think we should keep it as it was. It is annoying that one can abstract over self by name only in classes, but not in modules. And there's no hard reason why we should disallow it.