Make it a compile-time error if a library has `part "uri";` twice for the same uri.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
 {4th edition draft}\\
@@ skipping 6924 matching lines @@
       partHeader topLevelDefinition* EOF
     .
 \end{grammar}
 
 \LMHash{}
 A {\em part header} begins with  \PART{} \OF{}  followed by the name of the library the part belongs to.  A part declaration consists of a part header followed by a sequence of top-level declarations.
 
 \LMHash{}
 Compiling a part directive of the form \code{\PART{} $s$;} causes the Dart system to attempt to compile the contents of the URI that is the value of $s$. The top-level declarations at that URI are then compiled by the Dart compiler in the scope of the current library. It is a compile-time error if the contents of the URI are not a valid part declaration. It is a static warning if the referenced part declaration $p$ names a library other than the current library as the library to which $p$ belongs.
 
+\LMHash{}
+It's a compile-time error if the same library contains two part directives with the same URI.
+

[eernst, 2016/09/26 14:26:36]

At first, it seemed reasonable to put a criterion here which allows for
detecting that two textually distinct URIs denote the same part file (I guess
that's not a "library" so we need to say 'file' here).

However, the spec says 'This specification does not discuss the interpretation
of URIs, with the following exceptions.', where the exceptions includes 'any
relative URI is interpreted as relative to the location of the current library.'

So we can have trivial differences (like "foo.d\art" vs. "f\u{6F}o.dart") if
'URI' means "source code" rather than "semantic value of source code", and we
can have non-normalized relative paths. Otherwise we can't have different URIs
and rely on any spec support for concluding that they denote the same file.

I conclude that we can't actually have any meaningful checks for "different URI,
but same file", so I'd tend to prefer that we forget about it.

[Lasse Reichstein Nielsen, 2016/09/26 16:40:57]

I considered something similar. Since I wrote the current Uri class
implementation, I know exactly which normalizations we apply, but that's not
necessarily the only possible normalizations. Specifying them seems overkill, so
I'd prefer to leave it up to the implementation to decide which URIs are
considered equal and which are not, as long as it's consistent and actually
identical strings do generate equal URIs.

 \subsection{Scripts}
 \LMLabel{scripts}
 
 \LMHash{}
 A {\em script} is a library whose exported namespace  (\ref{exports}) includes a top-level member named  \code{main}. It is a static warning if the static type of \code{main} is not assignable to a function type or is a function type with more than two required parameters.
 
 A script $S$ may be executed as follows:
 
 \LMHash{}
 First, $S$ is compiled as a library as specified above. Then, the top-level function \code{main} that is in the exported namespace of $S$ is invoked. If \code{main} has no positional parameters, it is invoked with no arguments. Otherwise if \code{main} has exactly one positional parameter, it is invoked with a single actual argument whose runtime type implements \code{List$<$String$>$}.  Otherwise \code{main} is invoked with the following two actual arguments:
@@ skipping 942 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------