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

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index cfd15366a65a5c01b149210f8a1bfb4a021a770d..363908843ef747097acecefef97f43cd83d5f173 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -6942,6 +6942,9 @@ A {\em part header} begins with  \PART{} \OF{}  followed by the name of the libr
 \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}