Document use of compiler_builtins with no_std binaries

[ranweiler]

See discussion in #43264.

The docs for the compiler_builtins_lib feature were removed in
PR #42899. But, though the compiler_builtins library has been
migrated out-of-tree, the language feature remains, and is needed to
use the stand-alone crate. So, we reintroduce the docs for the
feature, and add a reference to them when describing how to create a
no_std executable.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @frewsxcv (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[aidanhs]

Thanks for the PR @ranweiler! We'll check in now and again to make sure @frewsxcv or another reviewer gets to this soon.

However, it looks like our tidy check is currently failing with

[00:02:43] tidy error: The Unstable Book has a 'library feature' section 'compiler_builtins_lib' which doesn't correspond to an unstable library feature

[frewsxcv]

hmm, so it looks like the tidy check is failing because it doesn't know about this compiler_builtins_lib.

for reference here's the code for the unstable book tidy lint.

also, here's the function that gets called to retrieve the unstable language features.

[ranweiler]

Ha, thanks @frewsxcv, I was just looking at that exact code. I found the problem. In the PR I cite above, we here add src/libcompiler_builtins to the list of directories to skip in map_lib_features here. However, that directory is where the unstable library feature is defined. I'll add a commit to revert that change.

[ranweiler]

Ouch, I amended my commit to revert the blacklist, and it resulted in a whole slew of new tidy errors. Working on it locally.

[ranweiler]

(Note to self: we can locally repro the CI tidy failure by invoking ./x.py test src/tools/tidy/)

Update: I now see what the problem is. Even if I hack tidy to narrowly whitelist certain parts of libcompiler_builtins, a bunch of spurious tidy checks still fail within. Really, the only thing I want to do is ensure tidy knows about the unstable compiler_builtins_library feature. AFAICT, this is the only documented feature that gets defined out-of-tree, at least among the top-level submodules in the skip list in tidy::filter_dirs. The unstable liblibc feature is defined in in the src/liblibc submodule, but doesn't have an associated unstable feature doc in the Unstable Book, so we seemingly haven't run into this problem before.

What would we like to see happen here? Is it important that tidy only discovers the unstable features, or are we okay with manually inserting some into tidy::features::collect_lang_features? (cc @alexcrichton)

[alexcrichton]

@ranweiler want to just explicitly whitelist it to avoid checking it?

[alexcrichton]

@bors: r+

Thanks!

[bors]

📌 Commit b22634c has been approved by alexcrichton

[frewsxcv]

@bors rollup r-

[00:44:47] Linkcheck (x86_64-unknown-linux-gnu)

[00:44:53] unstable-book/print.html:1045: broken link - unstable-book/library-features/compiler-builtins-lib.html

[00:44:53] unstable-book/language-features/lang-items.html:248: broken link - unstable-book/library-features/compiler-builtins-lib.html

[00:44:54] thread 'main' panicked at 'found some broken links', /checkout/src/tools/linkchecker/main.rs:49:8

[ranweiler]

Alright, I think I had some stale local state, but everything looks good now!

r? @alexcrichton

[alexcrichton]

@bors: r+

[bors]

📌 Commit e74f611 has been approved by alexcrichton