half of me wants to say "awesome, cool, thanks!", but the other half wants to say this would probably better be handled by an external linting tool. @som-snytt wdyt? is there an argument to be made that it belongs in this codebase?

The argument for xlinting 1l is that it's scalac's fault. The JLS says don't do that, we've always known it was bad, and scala had a chance to do something about it and didn't. Propensive suggested deprecating outright. And why have two ways of doing the same thing? as the tiresome refrain goes. This is the next best thing. Note that lower el makes more sense when you call it a long instead of a Long.

The argument to mitigate the error on leading zero is that octal syntax is no longer a thing. Unwinding the error is a scalac change; whether to retain any warning for purposes of migration is a coin toss, as its purpose is to alert people who use octal syntax and need to be warned that they mistakenly used it intentionally in scala. Arguably the onus is on scala for ever supporting it.

Propensive suggested deprecating outright

that sounds appealing

Try it, you'll like it.

The new warning-filtering reporting system will make it easy to ignore, in case you are using your favorite password in code: 01l, like oil and water.

@SethTisue there were tricky Lukas tests with 42l in strings that fail if they compile with warnings. But there was also the Serial...StabilityTest which I scratched my head about then remembered there is a restarring that hasn't happened? Isn't that easy enough to pull a lever for?

On the other numeric literal PR, I was like, I thought leading zero didn't error anymore. Well, it's hung up in this PR, which ought to be an easy win. Go team! Win! Win! Win!

Edit: oh right, I split this off from the other PR, figuring that half of a no-brainer should be twice as easy.