================
@@ -986,6 +989,14 @@ def warn_module_conflict : Warning<
InGroup<ModuleConflict>;
// C++20 modules
+def err_pp_module_name_is_macro : Error<
+ "%select{module|partition}0 name component %1 cannot be a object-like
macro">;
+def err_pp_module_expected_ident : Error<
+ "expected %select{identifier after '.' in |}0module name">;
----------------
hubert-reinterpretcast wrote:
The `.` is technically part of the _pp-tokens_ following the module name in
such a case. In other words, this is a special case where we _do_ currently
diagnose the `;`/`[` restriction on the _pp-token_ following the module
name/partition in the preprocessor.
Contrast with the case where the module name is followed by `(` and the last
component is the name of a function-like macro. In that case, the `;`/`[`
restriction does not immediately apply (because it applies after macro
expansion), but we currently diagnose it in phase 7 using the `;`/`[`
restriction.
TL;DR: Instead of having this preprocessor diagnostic, there should be
preprocessor diagnostics for the disallowed `(` case and for the `;`/`[`
restriction.
https://github.com/llvm/llvm-project/pull/107168
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits