Delete the `cfg(not(parallel))` serial compiler
Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead.
But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now.
Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways.
But this is quite suboptimal:
- the maintenance burden still sucks
- we're not testing the serial compiler in nightly
Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now.
Let the knight slay one head of the two-headed dragon!
#113349
Note that the default is still 1 thread, as more than 1 thread is still fairly broken.
cc `@onur-ozkan` to see if i did the bootstrap field removal correctly, `@SparrowLii` on the sync parts
Since it's inception a long time ago, the parallel compiler and its cfgs
have been a maintenance burden. This was a necessary evil the allow
iteration while not degrading performance because of synchronization
overhead.
But this time is over. Thanks to the amazing work by the parallel
working group (and the dyn sync crimes), the parallel compiler has now
been fast enough to be shipped by default in nightly for quite a while
now.
Stable and beta have still been on the serial compiler, because they
can't use `-Zthreads` anyways.
But this is quite suboptimal:
- the maintenance burden still sucks
- we're not testing the serial compiler in nightly
Because of these reasons, it's time to end it. The serial compiler has
served us well in the years since it was split from the parallel one,
but it's over now.
Let the knight slay one head of the two-headed dragon!
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
- Sort dependencies and features sections.
- Add `tidy` markers to the sorted sections so they stay sorted.
- Remove empty `[lib`] sections.
- Remove "See more keys..." comments.
Excluded files:
- rustc_codegen_{cranelift,gcc}, because they're external.
- rustc_lexer, because it has external use.
- stable_mir, because it has external use.
Before, it said "global_allocator does nothing". Now it gives you
suggestions for what to do if you want to change the global allocator
(which is likely the main reason you'd be reading the comment).
This is the first (known) step towards starting to use `unix_sigpipe` in
the wild. Eventually, `rustc_driver::set_sigpipe_handler` can be removed
and all clients can use `unix_sigpipe` instead.
For now we just start using `unix_sigpipe` in once place: `rustc`
itself.
It is easy to manually verify this change. If you remove
`#[unix_sigpipe = "sig_dfl"]` and run `./x.py build` you will get an ICE
when you do `./build/x86_64-unknown-linux-gnu/stage1/bin/rustc --help |
false`. Add back `#[unix_sigpipe = "sig_dfl"]` and the ICE disappears
again.
In practice, this doesn't matter very much because the script takes ~no time to run.
But this makes `CARGO_LOG=info` easier to read, and theoretically saves a few milliseconds.
Add Windows application manifest to rustc-main
Windows allows setting some runtime options using a manifest file. The format of the XML file is documented here: https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests
The manifest file in this PR does three things:
* Declares which Windows versions we support. This may help avoid unnecessary compatibility shims.
* Uses the UTF-8 code page. While Rust itself uses UTF-16 APIs, other code may rely on the code page.
* Makes the application long path aware (if also enabled by the user). This allows for the current directory to be longer than `PATH_MAX`.
These changes only affect the `rustc` process and not any other DLLs or compiled programs.
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
