Added tests for structurally invalid language tags in DisplayNames.prototype.of()

[ben-allen]

Previously no test coverage for cases where {type: 'language'}, created tests for structurally invalid tags.

fix #3840

[gibson042]

Can you elaborate on why you think this is invalid? It looks to me like a valid Unicode locale identifier with unicode_language_id "en" and Unicode locale extension sequence "-u-hebrew", which includes the attribute "hebrew" and no keywords.

[ben-allen]

When type is "language", code has to be a valid unicode_language_id. See 12.5.1. Although the string in question is a valid unicode_locale_id, a unicode_language_id can only contain unicode_language_subtag, unicode_script_subtag, unicode_region_subtag, and unicode_variant_subtag, so strings with singletons are necessarily invalid.

[ben-allen]

Though now that I'm looking at it: doesn't the test in 12.5.1.1.a duplicate the test in IsStructurallyValidLanguageTag? Seems like all it does is save having to do the ASCII-lowercase at the start of IsStructurallyValidLanguageTag.

[gibson042]

When type is "language", code has to be a valid unicode_language_id. See 12.5.1. Although the string in question is a valid unicode_locale_id, a unicode_language_id can only contain unicode_language_subtag, unicode_script_subtag, unicode_region_subtag, and unicode_variant_subtag, so strings with singletons are necessarily invalid.

👍

Though now that I'm looking at it: doesn't the test in 12.5.1.1.a duplicate the test in IsStructurallyValidLanguageTag? Seems like all it does is save having to do the ASCII-lowercase at the start of IsStructurallyValidLanguageTag.

Let's see... CanonicalCodeForDisplayNames step 1.a ensures that the input is an isolated Unicode language identifier (i.e., a language subtag with optional script subtag or a script subtag, in either case optionally followed by a region subtag and/or any number of variant subtags but NOT by singleton subtags or any other subtags), and step 1.b ensures that it does not use backwards compatibility syntax (IsStructurallyValidLanguageTag step 3 rejecting e.g. "en_GB" and "root" and "Latn-DE" per the respective UTS #35 Part 1 Core, BCP 47 Conformance "backwards compatibility" bullet points) or contain duplicate variant subtags (IsStructurallyValidLanguageTag step 6 rejecting e.g. "de-1996-fonipa-1996") that would both pass the preceding syntax check. So I like the current state of ECMA-402 text, and also the coverage being added in this PR.

[gibson042]

Suggested change

	assert.throws(RangeError, function() {
	displayNames.of('enxx');
	}, 'invalid language subtag (4 letters)');
	assert.throws(RangeError, function() {
	displayNames.of('enxx');
	}, 'invalid language id - starts with a script subtag (4 letters)');

But actually, how does this differ from "tries to use backwards compatibility feature (bare script subtag)" below?

[ben-allen]

oh, fair! let me take that one out...

[gibson042]

Thanks so much for working on these! ❤️

[gibson042]

A few message consistency suggestions and assertion tweaks, but this looks good. Thanks again!

[anba]

Nit: Does this test actually use any features from Intl.DisplayNames-v2?

[ben-allen]

whoops -- fixed!

[ptomato]

All comments seem to have been addressed and we have an approval from Richard; I gave it a quick look additionally and it looks good. Merging now, sorry for the long wait.