Don't require the build_lib flag

[nrc]

rls.toml was meant to be a temporary fix. However, it feels like for all but the simplest projects, some customistion using it is required. I would like more to work by default. I'm not sure how to accomplish this. Maybe we can make better guesses from the project directory structure or maybe we can query Cargo.

TODO step 1 - enumerate ways we need to improve, then think about how we can do that.

[luser]

This feels sort of related to the cargo build plan work, in that you want to know what cargo is going to build for the current crate.

[euclio]

I guess one way to improve is removing the need for the build_lib flag. It seems like I have to add this one to every project.

[nrc]

Note: we now use client-side config, rather than rls.toml, but the point remains.

I guess one way to improve is removing the need for the build_lib flag. It seems like I have to add this one to every project.

This does seem to come up a lot. I wonder if we can change the default here. I don't know without checking what the effect of that might be. If we pass --lib to Cargo when it is not needed, does it break things? In particular, I'd be loathe to break 'hello world' out of the box.

[nrc]

So apparently passing --lib if there is only a bin (e.g., hello world) will break. We must be more clever than that, I guess. I'm not sure the best way to find out if there is a lib and a bin though. Maybe we can try, catch the error and try again without?

[euclio]

Could we check the cargo metadata?

…

On Sun, Aug 6, 2017, 5:45 PM Nick Cameron ***@***.***> wrote: So apparently passing --lib if there is only a bin (e.g., hello world) will break. We must be more clever than that, I guess. I'm not sure the best way to find out if there is a lib and a bin though. Maybe we can try, catch the error and try again without? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#332 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABTxFgq5lhfnlpwcBBdnraYbg7mJbeZ8ks5sVjQPgaJpZM4NpoiA> .

[Xanewok]

It's been inferred for a while (#438).
@nrc does this solve this?