Set display symlink in the same step

Because it uses the `$$` PID of the per-step shell.

(I think the pipe object it goes to may differ across steps too.)

This change gets interleaved high-level `cargo` output and lower
level `cc1` logging, without any other lower level commands as
would be obtained by telling `cargo` to produce more verbose
output. Those two kinds of output are displayed together from the
`cargo install` step. The full log of all `cc1` commands is again
displayed (unless there are no C or C++ builds, then it wouldn't be
created) in the subsequent step.

At this point, I think this approach is working better than the
preceding approach of deleting `cc1` (and, if present, `cc1plus`)
so `cargo` fails if anything uses it. This makes it easier to
figure out everything that will try to run `gcc` in ways that
result in `gcc` running `cc1` (or `cc1plus`), which should usually
only happen in order to compile C (or C++) code or to perform a
closely related operation.

The following two changes are deliberately not made at this time:

- Caching with the `rust-cache` action is not added back to this
  job. Although the build is no longer inefficient and complex (as
  in the approach of building, cleaning, breaking GCC, and building
  again) here there is a simpler reason not to cache: we want to
  find out if *any* build step, including for dependencies, is
  compiling C (or C++). Caching could potentially hide that, if a
  cached build artifact that had done so were able to be reused.

- No attempt is made to deparallelize the build. It would be useful
  to do something like `-j1` so that the interleaved log output
  would always pertain to an immediately adjacent step. However,
  that is usually already the case, and native code builds are not
  necessarily successfully deparallelized just by telling `cargo`
  to only do one task at a time, since they use custom commands
  (and even sometimes build systems) controlled through per-crate
  `build.rs` code and build dependencies. Also, since we're not
  caching, allowing parallelism may be useful to preserve speed.
  (The `flock` command is only locking logging, not the actual
  compilations.)

Author: EliahKagan

.github/workflows/ci.yml

@@ -70,7 +70,7 @@ jobs:
           #!/bin/sh -e
           printf '%s\n' "$0 $*" |
             flock /run/lock/wrapper1.fbd136bd-9b1b-448d-84a9-e18be53ae63c.lock \
-            tee -a -- /var/log/wrapper1.log ~/ci-stdout >/dev/null
+            tee -a -- /var/log/wrapper1.log ~/display >/dev/null  # We'll link ~/display later.
           exec "$0.orig" "$@"
           EOF
 
@@ -85,13 +85,13 @@ jobs:
 
           chmod +x /usr/local/bin/wrap1 /usr/local/bin/wrapper1
           mkdir /run/lock/wrapper1.fbd136bd-9b1b-448d-84a9-e18be53ae63c.lock
-          (set -x; ls -l "/proc/$$/fd/1")  # See what's going on.
-          ln -s -- "/proc/$$/fd/1" ~/ci-stdout
 
           find /usr/lib/gcc \( -name cc1 -o -name cc1plus \) \
             -print -exec /usr/local/bin/wrap1 {} \;
       - name: Build max-pure with minimal dev tools and log cc1
-        run: cargo install --debug --locked --no-default-features --features max-pure --path .
+        run: |
+          ln -s -- "/proc/$$/fd/1" ~/display  # Bypass `cc1` redirection.
+          cargo install --debug --locked --no-default-features --features max-pure --path .
       - name: Show logged C and C++ compilations (should be none)
         run: |
           ! cat /var/log/wrapper1.log