I've just created the rust-linting GitHub org and invited those interested. The organization doesn't yet have anything in it.
1 Like
Something simmilar is already possible, using -Zsave-analysis=yes flag. It seems that this is used by rls (rls-data crate can be used to deserialize data). Curently it is rather limited, but can still provide some usefull information, like type of variables. I managed to quickly hack some example of potential usage: GitHub - macpp/json_lint_example
maybe just improving this api could be good place to start?
I would caution against just incrementally improving save_analysis. As far as I know, it was never designed as a potentially public API. Makes sense to critically re-evaluate the specific format before opening it up to consumers.
On thing I'd like to highlight is that there is a space where such APIs are versioned independently of the compiler. I had a number of discussions around this.
This doesn't mean that none of the compiler APIs should be versioned with the main compiler version.
But for some concerns, an external version that communicates once things break (and how!) may be just enough. That also means that "third-party" compilers are okay to not implement that interface if they want to.
Honestly that would be great! Certainly something to consider.
OK, I'm feeling a little dense here, so please forgive me if this design should be obvious. Do you mean that the APIs are designed for introspection of some kind, so that code can query what APIs are supported, all at runtime? If so, I'm all for it, and I wish more APIs had that kind of interface!
Just to add onto this, it may be useful to define some kind of interface that can be used at compile time, or within build.rs scripts so that code can be built to statically work around differences.
This is not about the runtime capabilities.
But it is possible to have stabelish API provided by the Rust project that is not part of the semver guarantee of the compiler frontend. Imagine a library used in the compiler that gives access to certain info, let's call this lib "libbubbles". We can ship that library with its own versioning scheme, but say "rustc 1.99 includes libbubbles 6" and "rustc 1.106 includes libbubbles 7". We then don't have to support this interface forever, but people will be made aware of breakage through normal semver methods.
This is a massive improvement on the current state of things of many of those libraries that just break at random times.
It's also pragmatic, as many tool providers already track unstable internal APIs and have resources available to follow those changes (and e.g. support multiple libraries as backends)
1 Like
Thank you for the clarification.
OK, I see what you're suggesting, and I think it's a good idea. Instead of people linking against the libbubbles crate, each compiler would reexport the crate within their own interfaces, so breaking changes to the API's symbols are automatically exposed to the end user when they try to compile because the symbols will change (as long as they aren't trying to simultaneously link against the libbubbles crate directly). The only 'introspection' one may want is a constant function that returns the semantic version information of the libbubbles crate so you can compare to see if it's what you expected, maybe as a semver::Version instance. That way if the crate's symbols haven't changed, but the meaning of the APIs have changed, you can still have a hope of figuring it out at runtime.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.