Fix #7781: Loosen check for classes in wrong directory

[odersky]

The previous check demanded that the package prefix of a file corresponds
one-to-one with the directory name. This makes it illegal to have classes
in nested package clauses inside a file, which seems unreasonable. We now
only require that the file path is a prefix of the package path.

[nicolasstucki]

The issue number on the commit should be #7781. Otherwise LGTM.

[smarter]

This also lacks a test.

[nicolasstucki]

@smarter do you know how to create a test that triggers this warning?

[smarter]

Use tests/pos-special/sourcepath and tests/neg-custom-args/sourcepath

[odersky]

Isn't this going to enter classes with the wrong owner?

I don't think so. Why would it?

This also lacks a test.

Well, in a sense the quoted.Expr example is the test. That's what failed before, anyway.

I won't be able to work on this anymore, but it needs to be part of the release. @smarter or @nicolasstucki maybe you want to add a test? If there's no time for that let's merge anyway.

[smarter]

Isn't this going to enter classes with the wrong owner?

I don't think so. Why would it?

Because owner comes from the path and will be the same for everything entered by enterScanned. Demonstration with this PR:

// A.scala
package foo
package bar

class A

// B.scala
type Bla = foo.bar.A

% mkdir sp/foo
% mv A.scala sp/foo
% dotc -sourcepath sp B.scala
-- [E008] Member Not Found Error: B.scala:1:15 ------------------------------
1 |type Bla = foo.bar.A
  |           ^^^^^^^
  |           value bar is not a member of foo - did you mean foo.A?

No symbol was created for foo.bar, let alone foo.bar.A, and A was mistakenly added in foo.

I won't be able to work on this anymore, but it needs to be part of the release

I think merging #7784 would be more conservative.

[odersky]

@smarter I see what you mean. That aspect did not change. So, basically, outline parsing with nested packages was broken and is still broken now. #7784 "fixes" this by not using the feature in our own codebase. But others will run into the same problem.

So I think we should either fix it or disable it (by issuing a "not implemented error") before the release.

[smarter]

So, basically, outline parsing with nested packages was broken and is still broken now.

But before this PR the same code would have lead to a warning "class A is in the wrong directory." and wouldn't have added A to foo. Is there some other scenario where current master would add the symbol anyway ?

[odersky]

But before this PR the same code would have lead to a warning "class A is in the wrong directory." and wouldn't have added A to foo.

That's not quite as bad, but still counts as broken. The problem is, #7784 changes the public API of the core Type and Expr types in a non-desirable way to circumvent our lack of support for nested packages. So I much prefer we fix it instead.

[odersky]

I see it's not so easy to fix, since there is quite involved logic in Namer for creating packages. It's not clear we want to push all that into the outline parser. So, let's close this and revive #7784.