Support analyzing a specific binary in project#373
Conversation
| let current_package = ws.current().unwrap(); | ||
| let targets = current_package.targets(); | ||
|
|
||
| let bins = { |
There was a problem hiding this comment.
Declared like this, at this scope, because CompileFilter accepts a slice of names that has to live at least as long as CompileOptions, Workspace
There was a problem hiding this comment.
This seems odd - the outer block shouldn't introduce any new scopes here?
nrc
left a comment
There was a problem hiding this comment.
Basically looks good, some minor points inline
| let current_package = ws.current().unwrap(); | ||
| let targets = current_package.targets(); | ||
|
|
||
| let bins = { |
There was a problem hiding this comment.
This seems odd - the outer block shouldn't introduce any new scopes here?
src/build.rs
Outdated
| } else { | ||
| let mut bins = targets.iter().filter(|x| x.is_bin()); | ||
| let bin = bins.find(|x| x.name() == rls_config.build_bin); | ||
| match bin { None => vec![], Some(bin) => vec![bin.name().to_owned()]} |
There was a problem hiding this comment.
we should warn the user if they specify a bin which we then don't use. Not sure how best to do that - at least we should have a debug! message, but maybe we should also fail compilation with a message?
There was a problem hiding this comment.
Oh, right! While I worked on this, I implemented also returning notifications from build phase and passing them to the user, but I thought I can't use return any meaningful message for now (e.g. for implicit/detected targets by cargo), so I just separated that and didn't include it. But we definitely can here, as bin target has to be explicitly named in the manifest file! The notification bit is here, I can push PR with that later. For now is debug! okay?
Added
build_binconfiguration, which allows to specify which crate should be compiled and analyzed. When bothbuild_libandbuild_binare specified,build_libis preferred.