When using *Command Line Tools for Xcode* version 15.0, clang will warn about
`argument unused during compilation: '-stdlib=libc++'` if this flag is present
when compiling C files only (i.e. no C++ files).

To avoid this warning, we can add the flag only to CXXFLAGS and not to CFLAGS.

…rsan68

Don't pass `-stdlib=libc++` when building C files on macOS

When using *Command Line Tools for Xcode* version 15.0, clang will warn about `argument unused during compilation: '-stdlib=libc++'` if this flag is present when compiling C files only (i.e. no C++ files).

To avoid this warning, we can add the flag only to CXXFLAGS and not to CFLAGS.

---

[Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/clang.20warning.3A.20argument.20unused.20during.20compilation.20.28libc.2B.2B.29)

…ir, r=Mark-Simulacrum

bootstrap/setup: create hooks directory if non-existing

When running `./x setup` on a local repository I chose to install a `pre-push` git hook, but this happened:

```shell
Would you like to install the git hook?: [y/N] y
error: could not create hook .git/hooks/pre-push: do you already have the git hook installed?
No such file or directory (os error 2)
thread 'main' panicked at src/core/build_steps/setup.rs:462:9:
install_git_hook_maybe(&config) failed with No such file or directory (os error 2)
```

This was caused because the `.git/hooks` directory did not exist in my local repository. Creating it manually and re-running the command works fine.

This PR tests for the above directory and if it does not exist then it _tries_ to create it before hard linking the pre-push hook - we use `fs::create_dir()` and disregard the result (ie. it could fail if the directory was created in the meantime) and proceed to call `fs::hard_link()` all the same.

…, r=cjgillot

Remove unused LoadResult::DecodeIncrCache variant

…lstrieb

Add diagnostic items for a few of core's builtin macros

Specifically, `env`, `option_env`, and `include`. There are a number of reasons why people might want to look at these in lints (For example, to ensure that things behave consistently, detect things that might make builds less reproducible, etc).

Concretely, in PL/Rust (well, `plrustc`) we have lints that forbid these (which I'd like to [add to clippy as restriction lints](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Landing.20a.20flotilla.20of.20lints.3F) eventually), and `dylint` also has [lints that look for `env!`/`option_env!`](https://github.com/trailofbits/dylint/blob/109a07e9f27a9651ef33b6677ccaddd21466e97a/examples/general/env_cargo_path/src/lib.rs) (although perhaps not `include`), which would benefit from this.

My experience is that it's pretty annoying to (robustly) check uses of builtin macros without these IME, although that's perhaps just my own fault (e.g. I could be doing it wrong).

At `@Nilstrieb's` suggestion, I've added a comment that explains why these are here, even though they are not used in the compiler. This is mostly to discourage removal, although it's not a big deal if it happens (I'm certainly not suggesting the presence of these be in any way stable).

---

In theory this is a library PR (in that it's in library/core), but I'm going to roll compiler because the existence of this or not is much more likely something they care about rather than libs. Hopefully nobody objects to this.

r? compiler