test(dns): expand is_idn_hostname_uts46 coverage for the mapping step, Bidi and ContextO

[vtushar06]

I added 25 tests to test/dns/idn_hostname_uts46_test.cc. Core already passes all of them, so this is coverage, not a fix.

The file had 19 tests, against 98 for the strict function, and the gap was mostly in the parts of UTS #46 that only the lookup profile reaches.

What is new

• The order of the processing steps. 63 fullwidth ａ is 189 octets before mapping and 63 after, so the length limit has to be applied to the mapped form. ｘｎ--nxasmq6b only becomes an A-label after step 1, so the xn-- test has to run after mapping. There are also the cases where the mapping manufactures a violation that the input does not have - －abc becomes a leading hyphen, a．．b becomes an empty label, ab－－cd becomes -- in the third and fourth positions.
• The mapping table's own status classes. mapped reached through a few different routes (U+1D400, U+24D0, U+FB01), ignored via U+FE00, deviation via U+03C2 kept under nontransitional processing, and the NFC normalisation on its own.
• The Bidi rule's conditions 2, 3 and 4. The strict file covers condition 1 and the digit-first case; nothing covered an L inside an RTL label, an RTL label ending in ON, or a label mixing EN and AN.
• CONTEXTO appendix A.9. IdnaTestV2.txt states in its own header that "The CONTEXTO tests are optional for client software, and not tested here", so the suite file cannot cover this even though Core implements it. The extended Arabic-Indic digit rule and the per-label scope of A.8/A.9 are both exercised.

How I checked the expected values

Every assertion is the live verdict, read off the real functions through a driver linked against sourcemeta::core::dns rather than written by hand. Each test asserts both is_idn_hostname_uts46 and is_idn_hostname, so the pair also documents where the two profiles part company - 9 of the 25 differ between them.

Any input containing a byte a C string literal would mangle is emitted as an explicit-length std::string_view with a static_assert on the length, so a shortened literal fails to compile rather than silently testing something else.

sourcemeta_core_dns_unit builds and runs clean: 335 passed, 0 failed. clang-format applied, and the diff is additions only.

One case I deliberately left out: an A-label with an uppercase Punycode body. The strict function rejects it today, and asserting that would pin a verdict that RFC 5891 section 5.3 ("first ensuring that the A-label is entirely in lowercase"), RFC 5891 section 3.1 and RFC 3492 section 5 all point the other way. That seemed like the wrong thing to lock into a coverage PR, so I have raised it on the suite side instead.

RFC references

• UTS #46 section 4 and section 4.1
• RFC 5892 appendix A.8 and A.9
• RFC 5893 section 2

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[augmentcode]

🤖 Augment PR Summary

Summary: Expands UTS #46 IDN-hostname test coverage without changing production code.

Changes:

• Adds explicit-length UTF-8 fixtures for mapping-sensitive inputs.
• Covers post-mapping label-length boundaries and ignored code points.
• Tests ACE-prefix recognition and structural violations introduced by mapping.
• Exercises mapped, ignored, deviation, and NFC-normalization mapping statuses.
• Adds Bidi-rule cases for RTL labels and digit-class restrictions.
• Adds ContextO Arabic-Indic digit scenarios, including per-label scope.
• Compares UTS Support from() when passing a zero literal #46 lookup behavior with strict IDNA 2008 validation.

Technical notes: The fixtures use `static_assert` byte-length checks so embedded UTF-8 data is passed to the validators without C-string truncation.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestion posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

At test/dns/idn_hostname_uts46_test.cc:373, this label contains U+06F0 (EN) and U+0660 (AN) after an RTL character, so it already fails RFC 5893 condition 4 even if Appendix A.9 is disabled. Consequently, this assertion cannot provide the claimed negative ContextO/A.9 coverage.

Severity: low

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="test/dns/idn_hostname_uts46_test.cc">

<violation number="1" location="test/dns/idn_hostname_uts46_test.cc:370">
P3: This test's label mixes U+06F0 (Bidi_Class EN) and U+0660 (Bidi_Class AN) after an RTL character, so it already fails RFC 5893 condition 4 (no mixing of EN and AN in an RTL label) independent of the Appendix A.9 digit-block rule. The comment claims this exercises A.9's prohibition on mixing digit blocks, but the failure here doesn't isolate that rule; use an LTR label or another approach that avoids triggering the bidi rule so the A.9 rule is the actual cause of rejection.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: This test's label mixes U+06F0 (Bidi_Class EN) and U+0660 (Bidi_Class AN) after an RTL character, so it already fails RFC 5893 condition 4 (no mixing of EN and AN in an RTL label) independent of the Appendix A.9 digit-block rule. The comment claims this exercises A.9's prohibition on mixing digit blocks, but the failure here doesn't isolate that rule; use an LTR label or another approach that avoids triggering the bidi rule so the A.9 rule is the actual cause of rejection.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At test/dns/idn_hostname_uts46_test.cc, line 370:

<comment>This test's label mixes U+06F0 (Bidi_Class EN) and U+0660 (Bidi_Class AN) after an RTL character, so it already fails RFC 5893 condition 4 (no mixing of EN and AN in an RTL label) independent of the Appendix A.9 digit-block rule. The comment claims this exercises A.9's prohibition on mixing digit blocks, but the failure here doesn't isolate that rule; use an LTR label or another approach that avoids triggering the bidi rule so the A.9 rule is the actual cause of rejection.</comment>

<file context>
@@ -116,3 +118,268 @@ TEST(invalid_trailing_dot) {
+
+// appendix A.9 forbids the two digit blocks in one label
+TEST(invalid_extended_arabic_indic_mixed_with_arabic_indic) {
+  static constexpr char value[] = "\xd8\xa8\xdb\xb0\xd9\xa0";
+  static_assert(sizeof(value) - 1 == 6, "literal length");
+  const std::string_view input{value, 6};
</file context>

[jviotti]

Looks good! Keep in mind the new CLA CI new requirement, which is now a blocker for merging. Let me know when that's done!