Rollup merge of #67835 - euclio:delimiter-wording, r=Centril

tweak wording of mismatched delimiter errors

This PR improves the wording of the "incorrect delimiter" error messages. Here's a quick rationale:

- *"un-closed" -> "unclosed"*: "unclosed" is valid English, so there's no need to hyphenate the prefix. This should be pretty uncontroversial, I think.
- *"close delimiter" -> "closing delimiter"*: In my anecdotal experience, I've always heard "closing delimiter" or "closing parenthesis". In addition, the codebase already uses this terminology in comments and function names more than "close delimiter", which could indicate that it's more intuitive.
- "incorrect delimiter" -> "mismatched delimiter": "Incorrect delimiter" is vague; why is it incorrect? "mismatched" clearly indicates why the delimiter is causing the error.

r? @estebank

1 files changed, 4 insertions, 4 deletions

diff --git a/src/librustc_parse/parser/mod.rs b/src/librustc_parse/parser/mod.rs
index 6dcffcf0bd7..a2fa335cf72 100644
--- a/src/librustc_parse/parser/mod.rs
+++ b/src/librustc_parse/parser/mod.rs
@@ -1354,16 +1354,16 @@ crate fn make_unclosed_delims_error(
     let mut err = sess.span_diagnostic.struct_span_err(
         unmatched.found_span,
         &format!(
-            "incorrect close delimiter: `{}`",
+            "mismatched closing delimiter: `{}`",
             pprust::token_kind_to_string(&token::CloseDelim(found_delim)),
         ),
     );
-    err.span_label(unmatched.found_span, "incorrect close delimiter");
+    err.span_label(unmatched.found_span, "mismatched closing delimiter");
     if let Some(sp) = unmatched.candidate_span {
-        err.span_label(sp, "close delimiter possibly meant for this");
+        err.span_label(sp, "closing delimiter possibly meant for this");
     }
     if let Some(sp) = unmatched.unclosed_span {
-        err.span_label(sp, "un-closed delimiter");
+        err.span_label(sp, "unclosed delimiter");
     }
     Some(err)
 }