Use `once_cell` crate instead of custom data structure
Internally, we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate, which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one.
This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver`, is owned by a well-known community member (cc @matklad), and has a stable release. cc @rust-lang/compiler
`once_cell` has a slightly more minimal API than `Once`, which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`.
r? @Mark-Simulacrum
Otherwise inserting it to the `Binder` used by `trait_ref` would cause
problems. This is just to be extra carefult: we aren't going to
start recommending that the user start using HKTs anytime soon.
`mk_obligation_for_def_id` is only correct if the trait and self type do
not have any substitutions. Use a different method,
`mk_trait_obligation_with_new_self_ty` that is more clear about what is
happening.
Add core::future::IntoFuture
This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps!
cc/ @rust-lang/wg-async-foundations
## References
- Original PR adding `IntoFuture` https://github.com/rust-lang/rust/pull/65244
- Open issue to re-land `IntoFuture` (assigned to me) https://github.com/rust-lang/rust/issues/67982
- Tracking issue for `IntoFuture` https://github.com/rust-lang/rust/issues/67644
Allow rust-highfive to label issues it creates.
This is my first meaningful PR, I am unsure how to test this code so any pointers would be welcome!
I am about 50% sure it works.
On my machine, an error looks like:
Finished release [optimized] target(s) in 0.29s
Opening doc /git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html
command 'xdg-open (internal)' did not execute successfully; exit code: 4
command stderr:
gio: file:///git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html: Error when getting information for file “/git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html”: No such file or directory
Build completed successfully in 0:00:08
Rollup of 7 pull requests
Successful merges:
- #71829 (Fix suggestion to borrow in struct)
- #72123 (Stabilize process_set_argv0 feature for Unix)
- #72235 (Clean up E0590 explanation)
- #72345 (Clean up E0593 explanation)
- #72376 ([self-profling] Record the cgu name when doing codegen for a module)
- #72399 (Add fast-path optimization for Ipv4Addr::fmt)
- #72435 (rustllvm: Fix warnings about unused function parameters)
Failed merges:
r? @ghost
Stabilize process_set_argv0 feature for Unix
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
Fix suggestion to borrow in struct
The corresponding issue is #71136.
The compiler suggests that borrowing `the_foos` might solve the problem. This is obviously incorrect.
```
struct Foo(u8);
#[derive(Clone)]
struct FooHolster {
the_foos: Vec<Foo>,
}
```
I propose as fix to check if there is any colon in the span. However, there might a case where `my_method(B { a: 1, b : foo })` would be appropriate to show a suggestion for `&B ...`. To fix that too, we can simply check if there is a bracket in the span. This is only possible because both spans are different.
Issue's span: `the_foos: Vec<Foo>`
other's span: `B { a : 1, b : foo }`
Always generated object code for `#![no_builtins]`
This commit updates the code generation for `#![no_builtins]` to always
produce object files instead of conditionally respecting
`-Clinker-plugin-lto` and sometimes producing bitcode. This is intended
to address rust-lang/cargo#8239.
The issue at hand here is that Cargo has tried to get "smarter" about
codegen in whole crate graph scenarios. When LTO is enabled it attempts
to avoid codegen on as many crates as possible, opting to pass
`-Clinker-plugin-lto` where it can to only generate bitcode. When this
is combined with `-Zbuild-std`, however, it means that
`compiler-builtins` only generates LLVM bitcode instead of object files.
Rustc's own LTO passes then explicitly skip `compiler-builtins` (because
it wouldn't work anyway) which means that LLVM bitcode gets sent to the
linker, which chokes most of the time.
The fix in this PR is to not actually respect `-Clinker-plugin-lto` for
`#![no_builtins]` crates. These crates, even if slurped up by the linker
rather than rustc, will not work with LTO. They define symbols which are
only referenced as part of codegen, so LTO's aggressive internalization
would trivially remove the symbols only to have the linker realize later
that the symbol is undefined. Since pure-bitcode never makes sense for
these libraries, the `-Clinker-plugin-lto` flag is silently ignored.
