aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_def/src/body
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2020-05-14 10:23:34 +0100
committerGitHub <[email protected]>2020-05-14 10:23:34 +0100
commit5148d6dc66d80b375a98143dfbb556ec675bbffc (patch)
treefb803ca1ef8185c0e4738d41a8f0e74c0108324a /crates/ra_hir_def/src/body
parent6fde7f1b6bb30481a38c3346729dde9bd1b42c1a (diff)
parent9f0a7eb97b4e047cebbe51ffd6f9e2092dd63e00 (diff)
Merge #4405
4405: Make some stuff public so that they can be reused by other tools r=pksunkara a=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. Co-authored-by: Pavan Kumar Sunkara <[email protected]>
Diffstat (limited to 'crates/ra_hir_def/src/body')
0 files changed, 0 insertions, 0 deletions