"part" in lib and "part of" in bin breaks analyzer

[treeplate]

Dart SDK version: 3.1.0-246.0.dev (dev) (Fri Jun 23 01:04:39 2023 -0700) on "macos_arm64"
How to reproduce issue:
dart create foo
in foo/lib/foo.dart:

library foo;

part '../bin/foo.dart';

int x = 3;

in foo/bin/foo.dart:

part of '../lib/foo.dart';

void main(List<String> arguments) {
  print(x);
}

remove the test directory.
dart analyze:

Analyzing foo...              0.5s

  error • bin/foo.dart:4:9 • Undefined name 'x'. Try correcting the name to one that is defined, or defining the name. • undefined_identifier
  error • lib/foo.dart:3:6 • Target of URI doesn't exist: 'package:foo/bin/foo.dart'. Try creating the file referenced by the URI, or try using a URI for a file that
          does exist. • uri_does_not_exist

2 issues found.

dart run:

Building package executable... 
Built foo:foo.
3

[lrhn]

First: don't do that. Do not have dependencies that go into or out of lib using relative references. Always use package: URIs to refer to files in lib from the outside. Never refer to files outside of lib from inside.

I'm not sure anyone is wrong, they're just helping you in different ways.

The analyser is giving the library file the URI package:foo/foo.dart. That's reasonable, and prevents a lot of problems.

Then it tries to resolve ../bin/foo.dart against that package URI, giving package:foo/bin/foo.dart, because that's how a relative path is resolved against a package URI.

That file doesn't exist.

Resolving in the other direction is actually fine, because no package URI is involved, it's all local files. I'm guessing the analyzer fails that because it only gives one URI to each file, or because it helps you avoid file paths into lib/.

The dart run is actually wrong, because part files are not valid dart scripts. You should only be allowed to run a library file.

[eernstg]

Cf. #52575