Augmentation libraries can't be main libraries as well?

[eernstg]

Thanks to @sgrekhov for bringing up this question. The specification does not seem to mention the case where an augmentation library augments itself:

// Library 'main_lib.dart'.
library augment 'main_lib.dart';
import augment 'main_lib.dart';
...

Presumably, that would be an error?

It seems reasonable to assume that the import augment graph should be a tree, so we'd naturally ask a similar question about this:

// Library 'a.dart'.
library augment 'b.dart';
import augment 'b.dart';

// Library 'b.dart'.
library augment 'a.dart';
import augment 'a.dart';

It would presumably not be hard to create many kinds of cyclic import augment graphs, and I think they should all be errors.

Perhaps we need a rule about a regular import:

It is a compile-time error if a library imports uri, and uri denotes an augmentation library.

That is, a regular import directive can import an augmented library (containing import augment ..., but not library augment ...), but it cannot import an augmentation library (containing library augment).

[jakemac53]

Yes, we should block cycles like this.

[lrhn]

It should be an error.
If for no other reason than that a library augmentation file is not a library, so you can't import it directly. (It's an error to import or export a file, if that file is not a library file. A library augmentation file is not a library file.) Also cannot be included through a part-inclusion, because that requires the file to be a part file, which a library augmentation file also isn't.
(We do say that today:

It is a compile-time error if the specified URI of an import does not refer to a library declaration.

A library augmentation declaration is not a library declaration.)

That means that if your program (entry point library) actually refers transitively to a library augmentation file, then it's through an import augment declaration (or just augment - #3420), and then it's immediately a compile-time error if the library augmentation file header doesn't refer back to the parent file. Which it doesn't if it refers to itself.

So, today, it shouldn't be possible to include such a file in a program without getting a compile-time error.
It's really just the analyzer which needs to complain if it starts at a non-library file, and doesn't find a library file by following the parent-file links (part of and augment library URIs). A cycle would imply that.

We can say the same thing for

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

I don't think we say that this is an error today, but it's an error for a library to include a part file that doesn't point back to the library, which this one never would, so it cannot be part of a valid Dart program.

[eernstg]

Here's a proposal: #3676.

[eernstg]

The spec update in #3676 has been landed.