[C2x] Add test coverage for WG14 N2322

[aaron.ballman]

Summary

The changes in this paper add a new recommended practice. I had originally marked Clang as supporting this paper because we're not obligated to follow a recommended practice. However, in retrospect, it seems more useful to document whether we implement the recommendation or not. This adds a test for those changes. However, the recommended practice is just tricky enough to test, I wanted a second set of eyes on my test coverage to see if there's agreement I'm testing the right things and have come to the right conclusion.

[erichkeane]

I had two suggestions for more tests, but this is probably covering everything.

clang/test/C/C2x/n2322.c

45

I might suggest:

_Static_assert(555 == \
LI\
NE\
)

Which, is basically exactly what the first bullet point in J.1 is trying to figure out (it should be the opening character).

I think this is a repeat of the string-literal test, but it is basically exactly what they were talking about with PP-token.

Not a great addition to this file perhaps, but something with #warning might be a nice exercise of the pp-directive, to make sure it hits the diagnostics engine right?

[aaron.ballman]

Added an additional test case.

clang/test/C/C2x/n2322.c

45

I've added the test.

[erichkeane]

I'm OK with this either way, I think you've proved out the important cases.

[aaron.ballman]

Committed in f1c9ef311fa677992798d609b0445f1d7311a8f2 (forgot to link the review with the commit message, sorry), thank you for the reviews!

clang/test/C/C2x/n2322.c

+// RUN: %clang_cc1 -std=c2x -ast-dump %s | FileCheck %s
+
+/* WG14 N2322: partial
+ * Preprocessor line numbers unspecified
+ */
+void n2322() {
+  // The line number associated with a pp-token should be the line number of
+  // the first character of the pp-token.
+  "this string literal  \
+   spans multiple lines \
+   before terminating";
+// CHECK: ImplicitCastExpr {{.*}} <line:9
+// CHECK-NEXT: StringLiteral {{.*}} <col:3>
+
+  // The line number associated with a pp-directive should be the line number
+  // of the line with the first # token.
+  // Possible FIXME: The AST node should be on line 1002 if we take the line
+  // number to be associated with the first # token. However, this relies on an
+  // interpretation of the standard definition of "presumed line" to be before
+  // line splices are removed. The standard leaves this unspecified, so this
+  // may not represent an actual issue.
+  #\
+  line\
+  1000
+  "string literal";
+// CHECK: ImplicitCastExpr {{.*}} <line:1000
+// CHECK: StringLiteral {{.*}} <col:3>
+
+  // The line number associated with a macro invocation should be the line
+  // number of the first character of the macro name in the invocation.
+  //
+  // Reset the line number to make it easier to understand the next test.
+  // FIXME: The line number should be 2005 (first letter of the macro name) and
+  // not 2007 (closing parenthesis of the macro invocation).
+  #line 2000
+  #define F( \
+    )        \
+_\
+_LINE__
+
+  _Static_assert(F(\
+  \
+  ) == 2007);
+
+  // Reset the line number again for ease.
+  #line 2000
+  _Static_assert(2001 == \
+__LI\
+NE__\
+  );
+}

clang/www/c_status.html

</tr>
       </tr>
       <tr> <!-- Sep 2021 -->
         <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2755.htm">N2755</a></td>
         <td class="unknown" align="center">Unknown</td>
       </tr>
     <tr>
       <td>Preprocessor line numbers unspecified</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2322.htm">N2322</a></td>
-      <td class="full" align="center">Yes</td>
+      <td class="partial" align="center">
+        <details><summary>Partial</summary>
+        The line number associated with a macro invocation is not the line
+        number of the first character of the macro name in the invocation.
+        Additionally, Clang may not associate the line number of a pp-directive
+        with the first <code>#</code> token. As these are recommended practices
+        and not normative requirements, Clang's behavior is still conforming.
+        </details>
+      </td>
     </tr>
     <tr>
       <td>deprecated attribute</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2334.pdf">N2334</a></td>
       <td class="full" align="center">Clang 9</td>
     </tr>
     <tr id="Attributes">
       <td rowspan="3">Attributes</td>