Warn about dollars in names of definitions unless backticked

[som-snytt]

Warns on definitions named with embedded dollars, which can be written in backquotes to be accepted quietly.

Fixes #18234

Test from #18563

[sjrd]

which should be written in backquotes

They should not be written at all, in fact. ;)

[som-snytt]

This proposal aims to accommodate the two views, which are not entirely incompatible, that strict enforcement is required and yet Java doesn't need it so why does Scala?, where the question is posed with a large dosage of skepticism about warnings.

Here, there is no forking compiler option. Definitions with suspect names are disallowed, with a migration warning now and an error later. However, the workaround, to permit the identifier in backquotes, is quite natural and pleasant, as we have all come to savor backquotes in new syntactic contexts. Backquotes are not required for references (usages).

CB c includes the original izumi-reflect example.

A rewrite will be offered in a follow-up. The corner case is pattern variables, where it's not sufficient to simply wrap the identifier in backquotes.

[sjrd]

@Gedochao What's the warning policy for the feature freeze?

Should this be

Suggested change

	case IdentifierDollars extends MigrationVersion(`3.8`, `3.9`)
	case IdentifierDollars extends MigrationVersion(`3.10`, `3.11`)

at this point?

Or can we get away with

Suggested change

	case IdentifierDollars extends MigrationVersion(`3.8`, `3.9`)
	case IdentifierDollars extends MigrationVersion(`3.8`, `3.10`)

even though the warning would then be introduced in a patch version?

[Gedochao]

my gut says the former (3.10, 3.11), but I probably could be convinced otherwise.
We haven't had a precedent for this, I guess.
let's discuss it on today's Scala Core.

[som-snytt]

My favorite of the tests

class Cla$$( // error

[prolativ]

How would that work for $ as the name of an interpolator, e.g. for expressions like $"foo" in Apache Spark DSL? Usage of backticks doesn't even seem to be allowed by the parser.
Also asking from my personal interest about how this would affect users of https://github.com/VirtusLab/iskra (and potentially other DSL libraries using a similar syntactical pattern). Writing `$` would make the usage very inconvenient, killing productivity and making code extremely cluttered. Using a different placeholder character instead of $ would be technically doable but would destroy the visual/conceptual link with the original Spark syntax

[sjrd]

All of those were never supposed to use $ in identifiers.

The only valid use cases are specifically to reproduce an internal name generated by the compiler for obscure binary compatibility reasons. Using backticks is not the "blessed" way of using $. It's the way to silence the warning when you know 100% what you're doing.

[prolativ]

Or was I too hasty to complain? The spec says User programs should not **define** identifiers which contain ‘$’ characters
So I would just need to use backticks when defining $ and the users will not get any warning/errors on usages, right?

[sjrd]

They won't get any errors, but you still shouldn't define such identifiers. Unless you emulate the compiler's binary encoding and you know what you are doing.

[som-snytt]

@prolativ That is the intention here.

Warns on definitions named with embedded dollars

Backticks are not an absolute escape hatch because (per spec) it's implementation- or platform-dependent what can be permitted. In a separate issue, I'm addressing funky package names.

For my benefit, I checked the specese: "host systems may impose some restrictions". (The circumlocution "host system" seems to say the compiler is not required to reject illegal identifiers, but the runtime may crash.)

That said, I am not a hard-liner, through also not an arbiter. I considered special-casing lone dollar, since it encodes nothing. I was too lazy, however.

[som-snytt]

Demoted to "never error" because of the bureaucratic overhead.

Folks who want an error can ask for it in the usual way, viz., -Wconf.

A patch is offered on migration. Maybe it should always emit the patch? since that is a quickfix.

As noted above, edge case case x$1 => is not quickfixable, though it can be rewritten

case `x$1` @ _ =>

[som-snytt]

Had a good idea to check in Namer, but the completer loses a bit of context.

Edit: the special case is module names, which (it turns out) are a special kind. Avoid warning for case accessors, since it suffices to check the parameter. Don't use namePos, since that is for well-formed names and always drops a dollar suffix; instead, just calculate an error position.

Possible todo is to fix namePos and other usages of dropping the module suffix, which is valid only for ModuleClassName. (stripModuleSuffix excludes it but doesn't check for it.)