Auto merge of #13951 - epage:trace, r=ehuss

Add more high level traces

This accounts for more time when running rustc (which turns out to be a significant amount of time).

I'm less sure about the start/wait calls but I'm seeing very different results from different builds of `cargo` and some have some large amounts of unaccounted time that I want to dig into (and callgrind and and samply haven't helped).

src/cargo/core/compiler/build_context/target_info.rs

@@ -152,6 +152,7 @@ impl TargetInfo {
     /// invocation is cached by [`Rustc::cached_output`].
     ///
     /// Search `Tricky` to learn why querying `rustc` several times is needed.
+    #[tracing::instrument(skip_all)]
     pub fn new(
         gctx: &GlobalContext,
         requested_kinds: &[CompileKind],
@@ -878,6 +879,7 @@ pub struct RustcTargetData<'gctx> {
 }
 
 impl<'gctx> RustcTargetData<'gctx> {
+    #[tracing::instrument(skip_all)]
     pub fn new(
         ws: &Workspace<'gctx>,
         requested_kinds: &[CompileKind],

src/cargo/core/package.rs

@@ -654,6 +654,7 @@ impl<'a, 'gctx> Downloads<'a, 'gctx> {
     /// Returns `None` if the package is queued up for download and will
     /// eventually be returned from `wait_for_download`. Returns `Some(pkg)` if
     /// the package is ready and doesn't need to be downloaded.
+    #[tracing::instrument(skip_all)]
     pub fn start(&mut self, id: PackageId) -> CargoResult<Option<&'a Package>> {
         self.start_inner(id)
             .with_context(|| format!("failed to download `{}`", id))
@@ -793,6 +794,7 @@ impl<'a, 'gctx> Downloads<'a, 'gctx> {
     /// # Panics
     ///
     /// This function will panic if there are no remaining downloads.
+    #[tracing::instrument(skip_all)]
     pub fn wait(&mut self) -> CargoResult<&'a Package> {
         let (dl, data) = loop {
             assert_eq!(self.pending.len(), self.pending_ids.len());