analysis-status should set non-zero exit code when error encountered loading project

[leighmcculloch]

The rust-analyzer analysis-status <path> command is useful for checking that projects aren't introducing anything that breaks rust-analyzer for a project. Running this check is really helpful for teams that rely on rust-analyzer working smoothly, where even the introduction of something that is valid rust that breaks rust-analyzer is better to prevent rather than break the teams rust-analyzer experience.

This command outputs errors encountered with the project model. It would be helpful if when an error is encountered it causes the command's exit code to be non-zero so that things like build scripts or other scripts can run the command and take a different action based on that result without having to parse the string output of the command.

[flodiebold]

analysis-stats does not have any stable interface, and I would really not want build scripts running it. It's only intended for internal use (and debugging).

Also, we want rust-analyzer to just work, not to have projects trying to work around issues in RA (unless they're doing something really hacky that only works by accident in the first place, in which case they should just not do that). So I don't really see a need for such a check.

[leighmcculloch]

That's fair, at the moment I'm using analysis-status in CI and greping for project model errors, so it is still possible to use this in CI without the exit code being added in any case.

Whilst it would be great if all bugs could be fixed in RA, there are some issues, such as no support for cyclic dev dependencies (#2414 ) which may not be fixed, and if a developer accidentally introduces that into a project it will break peoples use of rust-analyzer. Running builds with cargo will work fine in situations like this but rust-analyzer will fail in subtle ways and people spend time debugging trying to understand why their IDEs don't provide functionality. This has happened a couple times on projects I work on.

CI is a great way to prevent code from being committed that isn't supported by developer tools.

[flodiebold]

I realize the cyclic dev dependencies issue has been open for a long time, but it should absolutely be fixed at some point. We should probably surface these errors to the user in a more prominent way.

I can't stop you from running analysis-stats in your CI, but you should be aware that this might break at any time 🙂

Anyway, I think this issue can be closed.

[leighmcculloch]

We should probably surface these errors to the user in a more prominent way.

Agreed, this would probably be a helpful way to highlight that a project cannot be parsed. I opened as a follow up: #13117.