codegen_llvm_back: improve allocations
This commit was split out from https://github.com/rust-lang/rust/pull/54864. Last time it was causing an LLVM OOM, which was most probably caused by not collecting the globals.
- preallocate vectors of known length
- `extend` instead of `append` where the argument is consumable
- turn 2 `push` loops into `extend`s
- create a vector from a function producing one instead of using `extend_from_slice` on it
- consume `modules` when no longer needed
- ~~return an `impl Iterator` from `generate_lto_work`~~
- ~~don't `collect` `globals`, as they are iterated over and consumed right afterwards~~
While I'm hoping it won't cause an OOM anymore, I would still consider this a "high-risk" PR and not roll it up.
Rollup of 13 pull requests
Successful merges:
- #56141 ([std] Osstr len clarity)
- #56366 (Stabilize self_in_typedefs feature)
- #56395 (Stabilize dbg!(...))
- #56401 (Move VecDeque::resize_with out of the impl<T:Clone> block)
- #56402 (Improve the unstable book example for #[marker] trait)
- #56412 (Update tracking issue for `extern_crate_self`)
- #56416 (Remove unneeded body class selector)
- #56418 (Fix failing tidy (line endings on Windows))
- #56419 (Remove some uses of try!)
- #56432 (Update issue number of `shrink_to` methods to point the tracking issue)
- #56433 (Add description about `crate` for parse_visibility's comment)
- #56435 (make the C part of compiler-builtins opt-out)
- #56438 (Remove not used `DotEq` token)
Failed merges:
r? @ghost
Remove not used `DotEq` token
Currently libproc_macro does not use `DotEq` token.
https://github.com/rust-lang/rust/pull/49545 changed libproc_macro
to not generate `DotEq` token.
make the C part of compiler-builtins opt-out
I'd like to be able to use Xargo to build a libstd without having a full C toolchain for the target. This is a start (but the fact that libstd is a dylib is still a problem).
However, compiler_builtin already has somewhat similar logic to not require a C compiler for wasm:
fe74674f6e/build.rs (L36-L41)
(WTF GitHub, why doesn't this show an embedded code preview??)
I wonder if there is a way to not have two separate mechanisms? Like, move the above wasm logic to some place that controls the libstd feature, or so? Or is it okay to have these two mechanisms co-exist?
Cc @alexcrichton
Improve the unstable book example for #[marker] trait
The previous one didn't actually use the Display&Debug bounds in any way, so I think this one is a bit more meaningful.
Stabilize dbg!(...)
Per FCP in https://github.com/rust-lang/rust/issues/54306 (which is ~1 day from completion).
r? @SimonSapin
The PR is fairly isolated so a rollup should probably work.
Deal with EINTR in net timeout tests
We've seen sporadic QE failures in the timeout tests on this assertion:
assert!(kind == ErrorKind::WouldBlock || kind == ErrorKind::TimedOut);
So there's an error, but not either of the expected kinds. Adding a
format to show the kind revealed `ErrorKind::Interrupted` (`EINTR`).
For the cases that were using `read`, we can just use `read_exact` to
keep trying after interruption. For those using `recv_from`, we have to
manually loop until we get a non-interrupted result.
Enable -mergefunc-use-aliases
If the Rust LLVM fork is used, enable the -mergefunc-use-aliases
flag, which will create aliases for merged functions, rather than
inserting a call from one to the other.
A number of codegen tests needed to be adjusted, because functions
that previously fell below the thunk limit are now being merged.
Merging is prevented in various ways now.
I expect that this is going to break something, somewhere, because
it isn't able to deal with aliases properly, but we won't find out
until we try :)
This fixes#52651.
r? @rkruppe
Consider references and unions potentially inhabited during privacy-respecting inhabitedness checks
It isn't settled exactly how references to uninhabited types and unions of uninhabited types should act, but we should be more conservative here, as it's likely it will be permitted to soundly have values of such types.
This will also be more important in light of the changes at https://github.com/rust-lang/rust/pull/54125.
cc @RalfJung
name-anon-globals should always be run at the very end of the pass
pipeline, as optimization passes (in particular mergefunc) may
introduce new anonymous globals.
I believe we did not run into this earlier because it requires the
rather specific combination of a) mergefunc merging two weak functions
b) compilation not using thinlto.
