Editor placeholders probably shouldn't be errors at parse time #3141
Description
Description
If you parse editor placeholders using string literals (e.g., `let x: ExprSyntax = "<#a#>"), it succeeds but you get a bunch of noise in the system logs (or in the debugger console, if running it there) from this function that generally logs parser errors from string literals:
However, I'd like to argue that editor placeholders shouldn't be errors that come from the parser. Since editor placeholders are treated as if they were identifiers (DeclReferenceExprSyntax nodes) during parsing, we should be allowed to have them in the AST without triggering error scenarios. swift-format already has code to identify these errors and downgrade them because we want to be able to format code in the IDE that is syntactically valid but for placeholders still in the source.
But a more interesting use case would be building syntax tools that actually use placeholders intentionally. For example, you could imagine writing a refactoring API that transforms ASTs from one shape to another, using placeholders as a way of extracting and then substituting nodes into a "spec": something like foo(a: <#a#>, b: <#b#>) to foo(a: <#a#>).bar(b: <#b#>). It would be nice to parse those with ExprSyntax(stringLiteral:) without triggering the error logging.
For users who want to forbid placeholders (like the compiler itself), a simple visitor could be provided that reports the locations of any DeclReferenceExprSyntax nodes that look like placeholders, which could be handled by that tool's own error reporting, removing the error itself from the core lexer/parser.
Thoughts?
Steps to Reproduce
No response