"unknown hint" should not be an error - it should itself be a hint that can be enabled/disabled

[arnetheduck]

Description

Error: unknown hint: LineTooLong

this is annoying to manage, when using multiple nim version - it happens in both directions, ie when a hint is added or when one is removed.

typically, when supporting multiple nim versions in a library, we still want to enable and disable hints based on the needs of that library - doing so in a nim-version-specific way is difficult.

we can even add a new hint called UnknownHint which users can turn into an error if they want.

Nim Version

1.6, 2.0, devel

Current Output

No response

Expected Output

No response

Possible Solution

No response

Additional Information

No response

[ringabout]

fwiw, the devel provides a conditional symbol for LineTooLong

ref #22412

@if not nimHasNolineTooLong:
  hint[LineTooLong]=off
@end

[arnetheduck]

fwiw, the devel provides a conditional symbol for LineTooLong

this does not help if the warning is part of a command line - nor does it help in nimble scripts (specially when nim used to interpret the nimble script is different from nim used at compile time for cross-version tests) and a number of other cases - the if is also annoying to type out and you cannot predict what new ones you will have to add to restore cross-version compatibility - this error only serves the break code for no really good reason.

[arnetheduck]

The problem is exacerbated by examples like LineTooLong which get removed on a whim / mood of @Araq's of the day without much input, discussion or breakage analysis - the tests Nim performs in this area does not include build scripts of projects that use the compiler (since the package tests run stuff their own way) - for this approach to provide basic backwards-compatibility, it cannot be an error like it is now.