Make some stuff public so that they can be reused by other tools

[pksunkara]

So, my little experiment of building a code analysis tool using rust-analyzer is successful. I am going to proceed to build the tool now. This PR makes the needed things public.

I know there were some things about trying to change stuff regarding loading workspaces, which would make it more easier for other tools to reuse. But, until then, it should be okay using this load_cargo fn.

Btw, if I were publish my tool, I would need the ra crates to be released. Since @matklad told me that he doesn't want to care about breaking stuff, I would propose the following.

Every monday, during the weekly release, we release a new pre v1 minor version of all the crates. That way, we don't need to care about breaking stuff but still have rust-analyzer on crates.io.

I made https://github.com/pksunkara/cargo-workspaces to help release workspace crates easily.

So, coming week, we start with 0.1.0, then week after that, we release 0.2.0 and then 0.3.0 etc.. until we decide on 1.0.0 which is probably when the compiler team also starts using the crates. There is no limit to the minor versions (we can even have 0.150.0 or 0.1500.0), so I don't see anything wrong with this strategy.

[pksunkara]

You can think of our analysis tool as an experiment for the Library-ification and analyzing Rust goal. 😄

[regexident]

As the initial author and one of the maintainers of cargo-modules I too would love to be able to replace our current DIY name/path resolution implementation with one that just taps into the tremendous work that has already been put into rust-analyzer. 🦾

Having access to rust-analyzer's guts would be tremendous! 🤩

As for the issue of having to deal with breaking changes: It really wouldn't be any worse than what one currently has to deal with by tapping into rustc_… crates.

[bors]

✌️ pksunkara can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

[pksunkara]

bors r+

Thanks @matklad. What were your thoughts about the release proposal?

[bors]

Build succeeded:

• Rust (macos-latest)
• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript

[matklad]

What were your thoughts about the release proposal?

I don't think it makes sense to maintain crates.io release infrastructure in this repository. If anybody wants to have ra crates on crates.io, they are explicitly encouraged to setup automatic publishing. The best way do do this would probably be to fork rust-analyzer, and setup a github-actions chron job, which fetches the latest rust-analyzer master/nightly/release, patches Cargo.toml and publishes stuff to crates.io.

I think I am also ok merging such auto-publishing scheme in this repository, under the following conditions:

• It does not make maintenance harder (so it should be a separate github actions workflow, rather than a patch to existing release.yaml)
• the cargo-toml pathcing logic is implemented as xtask
• master branch keeps all versions at 0.1.0, as it does today
• I won't be spending time fixing .yaml if it breaks :D

[pksunkara]

I think I am also ok merging such auto-publishing scheme in this repository, under the following conditions:

I will go ahead and do that. I can also take care of this part of the code for the future. Thanks.

[pksunkara]

So, I did a little bit of this. Ran into some issues like stdx already existing on crates.io, and also chalk not going to be following the same schedule. I will talk to someone from the chalk team and find out whats going to happen.

[regexident]

Any update on this by any chance, @pksunkara?

[pksunkara]

This has been finished. Check ra_ap_* crates on crates.io

[regexident]

Oh neat! Thanks! 🙏🏻