Remove workarounds and writeup of the emoji-in-unknown-prefix bug

This bug is now fixed in stable rustc.

See
rust-lang/rust#123696
rust-lang/rust#123752

Author: mattheww

src/proptesting.rs

@@ -4,7 +4,6 @@ use proptest::{
     strategy::{BoxedStrategy, Strategy},
     test_runner::{Config, TestCaseError, TestError, TestRunner},
 };
-use regex::Regex;
 
 use crate::Edition;
 use crate::{
@@ -17,13 +16,6 @@ use self::strategies::SIMPLE_STRATEGIES;
 
 mod strategies;
 
-macro_rules! make_regex_with_default_flags {
-    ($re:literal $(,)?) => {{
-        static RE: ::std::sync::OnceLock<regex::Regex> = ::std::sync::OnceLock::new();
-        RE.get_or_init(|| Regex::new($re).unwrap())
-    }};
-}
-
 /// Implements the `proptest` cli subcommand.
 pub fn run_proptests(strategy_name: &str, count: u32, verbosity: Verbosity, edition: Edition) {
     println!("Running property tests with strategy {strategy_name} for {count} iterations");
@@ -60,16 +52,7 @@ pub fn run_proptests(strategy_name: &str, count: u32, verbosity: Verbosity, edit
 ///
 /// Returns Unsupported for input that may trigger known problems.
 fn check_lexing(input: &str, edition: Edition) -> ComparisonStatus {
-    if edition == Edition::E2015 {
-        // In Rust 2015 and 2018, emoji in unknown prefixes aren't reported as an error.
-        // I think this is a rustc bug, so exclude such cases from testing.
-        // See https://github.com/rust-lang/rust/issues/123696
-        let re =
-            make_regex_with_default_flags!(r#"[\p{EMOJI}--!-~][\p{XID_Continue}\p{EMOJI}]*[#'"]"#);
-        if re.is_match(input) {
-            return ComparisonStatus::Unsupported("emoji-in-unknown-prefix".into());
-        }
-    }
+    // See the history of this function for how to use `Unsupported`
 
     let rustc = regularised_from_rustc(input, edition);
     let lexlucid = regularised_from_lexlucid(input, edition);

src/testcases.rs

@@ -214,8 +214,8 @@ pub const LONGLIST: &[&str] = [
     "qr# ",
     "qr#x",
 
-    // This is accepted in Rust 2015, but I think that's a rustc bug.
-    // https://github.com/rust-lang/rust/issues/123696
+    // See https://github.com/rust-lang/rust/issues/123696
+    // (Fixed in rustc 1.79)
     "🦁#",
 
     //// Double-quote forms

writeup/introduction.md

@@ -42,8 +42,6 @@ This description aims to accept input exactly if `rustc`'s lexer would.
 Specifically, it aims to model what's accepted as input to a function-like macro
 (a procedural macro or a by-example macro using the `tt` fragment specifier).
 
-> See [emoji-in-unknown-prefix] for an exception
-
 It's not attempting to accurately model `rustc`'s "reasons" for rejecting input,
 or to provide enough information to reproduce error messages similar to `rustc`'s.
 
@@ -92,5 +90,3 @@ The source code for this document and the accompanying lexer implementation is a
 [rfc3349]: https://rust-lang.github.io/rfcs/3349-mixed-utf8-literals.html
 [rfc3593]: https://github.com/rust-lang/rfcs/pull/3593
 
-[emoji-in-unknown-prefix]: rustc_oddities.md#emoji-in-unknown-prefix
-

writeup/rustc_oddities.md

@@ -1,19 +1,5 @@
 ## Rustc oddities
 
-### emoji-in-unknown-prefix in Rust 2015/2018 { #emoji-in-unknown-prefix }
-
-Rust 2015 and 2018 accept a form like `🦁#`
-(as input to a function-like macro),
-treating it as an identifier `🦁` followed by punctuation `#`.
-
-This is surprising, because `🦁` would normally be rejected as an identifier.
-
-I assume this is just a bug (filed as [#123696]).
-
-This document doesn't attempt to characterise this behaviour,
-and the comparable implementation doesn't attempt to imitate it.
-
-
 ### NFC normalisation for lifetime/label { #nfc-lifetime }
 
 Identifiers are normalised to NFC,
@@ -36,5 +22,3 @@ reaction to being given a spec to review.
 [playground-ident]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=aad27eb75b2774f16fc6b0981b770d56
 
 [rfc2457]: https://rust-lang.github.io/rfcs/2457-non-ascii-idents.html
-
-[#123696]: https://github.com/rust-lang/rust/issues/123696