Change built-in kernel targets to be os = none throughout

[Ericson2314]

Whether for Rust's own target_os, LLVM's triples, or GNU config's, the
OS-related have fields have been for code running on that OS, not code
hat is part of the OS.

The difference is huge, as syscall interfaces are nothing like
freestanding interfaces. Kernels are (hypervisors and other more exotic
situations aside) freestanding programs that use the interfaces provided
by the hardware. It's those interfaces, the ones external to the
program being built and its software dependencies, that are the content
of the target.

For the Linux Kernel in particular, target_env: "gnu" is removed for
the same reason: that -gnu refers to glibc or GNU/linux, neither of
which applies to the kernel itself.

Relates to #74247

[rust-highfive]

r? @lcnr

(rust_highfive has picked a reviewer for you, use r? to override)

[lcnr]

maybe r? @Mark-Simulacrum

[kloenk]

Those names sounds much better

[bors]

☔ The latest upstream changes (presumably #77943) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[Mark-Simulacrum]

Tentatively r? @joshtriplett

[Ericson2314]

Per the issue thread (just to make things easier for anyone just reading the PR), While I prefer this to the status quo, my first preference is removing these targets outright. having per-project targets baked into rustc seems like a layer violation and maintenance hazard anyways.

[joshtriplett]

LGTM.

r=me when ready.

[joshtriplett]

@Ericson2314 I understand what you mean by a "layering violation", but given that we don't have stable support for custom targets, and given that it seems extremely unlikely we'll stabilize that because it's so dependent on specific details of LLVM internals, I think we need to have at least minimal scaffolding for important specialized targets.

We also don't have full support for building std/core from source yet, let alone for replacing it with a crate from the ecosystem.

Right now, there really isn't any path towards stable support for such targets without at least some infrastructure-level support like this.

I'm not suggesting that we should have targets specific to using Rust as a plugin to arbitrary specific pieces of software, but the Linux kernel is a very popular and desirable target to be able to run Rust in, and it provides enough infrastructure that substantial portions of the standard library (including alloc and a fair bit of std) would work.

[Ericson2314]

@joshtriplett This was the main thing we discussed on the call.

It's my understanding that the plan for the -z build-std work to stabilize without needing to stabilizing any of the language features we need to build standard library crates.

How might this work? The tools merely need to authenticate that the crates being built are in fact the officials stdlib crates, and unlock the nightly features only for that code. Then there's no risk of user code using things it shouldn't.

It was also discussed that given how the timeline LLVM Linux work as progressed, there ought to be be plenty of runway to be on Nightly until such functionality is worked out if Rust is held to the same standard.

[Dylan-DPC-zz]

@Ericson2314 any updates? also you have a few conflicts to resolve

[ojeda]

given that it seems extremely unlikely we'll stabilize that because it's so dependent on specific details of LLVM internals

I don't think users in the freestanding world would mind if the target spec options themselves are documented to not be compatible between Rust releases. Being able to use a stable release of the compiler in such environments is usually way more important.

[Ericson2314]

OK the merge conflicts are fixed. I would still advocate for these targets to be removed, but I think merging this PR is still a (less controversial) improvement over the status quo, so happy if we start with that and return to the question of removal after.

[Dylan-DPC-zz]

@bors r=joshtriplett

[bors]

📌 Commit 9d25ccf has been approved by joshtriplett

[bors]

⌛ Testing commit 9d25ccf with merge cc8aa2c31407e3a9c742ab7f865e8820cc104379...

[bors]

💥 Test timed out

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

##[group]Virtual Environment
Environment: ubuntu-20.04
Version: 20210302.0
Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20210302.0/images/linux/Ubuntu2004-README.md
Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F
##[group]GITHUB_TOKEN Permissions
Actions: write
Checks: write
Contents: write

[JohnTitor]

@bors retry