feat: support --package to specify the package to profile

[tizee]

Solve #56 and #39 without breaking the architecture.

When implementing this feature, I found the method fn validate_target is redundant for validating the target. For Cargo builtin sub-commands, this is done by setting the field spec in CompileOptions. However, remove the method validate_target isn't enough.

The way Cargo used to construct a ComplieOptions is like following :

        let opts = CompileOptions {
            build_config,
            cli_features: self.cli_features()?,
            spec,
            filter: CompileFilter::from_raw_arguments(
                self.is_valid_and_present("lib"),
                self._values_of("bin"),
                self.is_valid_and_present("bins"),
                self._is_valid_arg("test")
                    .then(|| self._values_of("test"))
                    .unwrap_or_default(),
                self.is_valid_and_present("tests"),
                self._values_of("example"),
                self.is_valid_and_present("examples"),
                self._is_valid_arg("bench")
                    .then(|| self._values_of("bench"))
                    .unwrap_or_default(),
                self.is_valid_and_present("benches"),
                self.is_valid_and_present("all-targets"),
            ),
            target_rustdoc_args: None,
            target_rustc_args: None,
            target_rustc_crate_types: None,
            local_rustdoc_args: None,
            rustdoc_document_private_items: false,
            honor_rust_version: !self.is_valid_and_present("ignore-rust-version"),
        };

In implementation of CompileOptions::new , spec: ops::Packages::Packages(Vec::new()), makes the field spec an empty vector, which cause Cargo fail to find bin, example, bench for a virtual manifest. Unless we set the field spec explicitly to Packages::Default to tell Cargo to search the whole workspace. For the sake of time, I didn't spend too much time digging in the internal logic.

    pub fn new(config: &Config, mode: CompileMode) -> CargoResult<CompileOptins> {
        let jobs = None;
        let keep_going = false;
        Ok(CompileOptions {
            build_config: BuildConfig::new(config, jobs, keep_going, &[], mode)?,
            cli_features: CliFeatures::new_all(false),
            spec: ops::Packages::Packages(Vec::new()),
            filter: CompileFilter::Default {
                required_features_filterable: false,
            },
            target_rustdoc_args: None,
            target_rustc_args: None,
            target_rustc_crate_types: None,
            local_rustdoc_args: None,
            rustdoc_document_private_items: false,
            honor_rust_version: true,
        })
    }

I implement the feature by introducing a Enum type Package that corresponds to Cargo's Packages::Default and Packages::Packages(Vec<String>) respectively.

I do not insist on this and will gladly to use other approach i.e. if there is a huge refactor on architecture. Right now I'm using this patch for projects having more than one package.

[cmyr]

Thanks!

I'm not sure exactly how cargo Packages works, but playing with this patch it seems like a pretty significant improvement.

In particular, running this in a workspace where a given target name exists in only one package, it is able to find that target without me needing to specify --package at all.

Is the --package argument only necessary if there are multiple packages that contain a given target name? I believe this is the case, in which case we should clarify that in the documentation. :)

[cmyr]

Great, thank you for this contribution, it is much appreciated!

I'm going to merge this as-is, and then I'll do a separate PR myself that clears up some documentation and gets ready for a release. :)