Clarify how to report file level diagnostic or diagnostics related to an incorrect filename

Hi

I have a case where the filename is critical for it to be recognized and I would like to have my language server report to the client if that file is incorrectly named as a diagnostic. However, it is not clear for me how I would do it in my case for multiple reasons. To describe my situation, I am working with the following:

• debian/control. This file lists a number of "package names". As an example, it could have a package called foo.
• debian/${NAME}.install. This is a auxiliary file related to the package with name ${NAME}. The file is optional, so it might be there or not. If the package is foo, then the filename should be debian/foo.install.

What I want, is to be able to warn the user if they typoed the filename of debian/${NAME}.install (they wrote debian/foo.intsall rather than debian/foo.install). The current behavior is that a typo causes the file to silently be ignored by the tools that would pick up these auxiliary files.

Unlikely Java, there is nothing in debian/foo.install that references the filename that I can report as an error, Java has the public class Foo of a Foo.java where I could attach the diagnostic and that is the solution I have seen so far, but it does not apply to my case (see Extra details below for the rationale). My "goto" solution so far is to create the diagnostic such that the range of the diagnostic covers the entire auxiliary file, but I am not sure if it is the proper way to do it or just a work around on my part. The other alternative would be an empty range, but I recall reading somewhere (cannot find the source) that the client then decides how to interpret that and VSCode as an example would look for a word at that position.

An alternative is to associate the diagnostic with the package name in debian/control, even though the problem is not the package name or its metadata. I am already using that technique for when a package is missing a mandatory field (similar to a class not implementing all the abstract methods it is required to do). Still, I would like the specification to be more clear on how to solve this case, since I doubt it will be the last of time I meet this problem.

Extra details

Note that there are multiple auxiliary files of the listed pattern (such as debian/${NAME}.docs, or debian/${NAME}.service, etc.) and for some of them, the content is required for follow a third party specification (the .service would be a systemd Service file). So it is not possible for me to dictate that the auxiliary files follow a particular syntax. Though, it is not a problem for my language server to work with different file formats since it is already a polyglot.

No files or tests are identified. Start by reviewing the diagnostic behavior described for incorrectly named debian/${NAME}.install files and the existing language-server specification; clarify where a filename-only diagnostic should be attached and document the expected behavior for clients such as VSCode.