This option is largely there to help people to manage the memory usage
on their systems during the LLVM build. The linking phase is as usual
are the heaviest part of the build and if in an unlucky conincidence the
circumstances align to kick off N_CORES links at the same time, not even
hundreds of GiB of memory may suffice. It makes a lot of sense for
developers to set&forget this option unconditionally.
Not to mention, this option does not, in any way, affect the generated
code (at least as far as I know.) It really doesn’t matter what
option the CI build LLVM used here and/or if it matches with the user’s
configuration.
Finally, 0 actual link jobs implied by `download-ci-llvm` is guaranteed
to stay within the limits that are reasonable to set with this option.
Rollup of 4 pull requests
Successful merges:
- #106893 (Explain base expression for struct update syntax)
- #119769 (rustdoc: offset generic args of cross-crate trait object types when cleaning)
- #119772 (Fix an ICE that occurs after an error has already been reported)
- #119782 (rint intrinsics: caution against actually trying to check for floating-point exceptions)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: offset generic args of cross-crate trait object types when cleaning
Fixes#119529.
This PR contains several refactorings apart from the bug fix.
Best reviewed commit by commit.
r? GuillaumeGomez
Update cargo
14 commits in 2ce45605d9db521b5fd6c1211ce8de6055fdb24e..3e428a38a34e820a461d2cc082e726d3bda71bcb
2024-01-04 18:04:13 +0000 to 2024-01-09 20:46:36 +0000
- refactor: replace `iter_join` with `itertools::join` (rust-lang/cargo#13275)
- docs(unstable): doc comments for items and fields (rust-lang/cargo#13274)
- crates-io: Set `Content-Type: application/json` only for requests with a body payload (rust-lang/cargo#13264)
- fix: only inherit workspace package table if the new package is a member (rust-lang/cargo#13261)
- feat(cli): add colors to `-Zhelp` console output (rust-lang/cargo#13269)
- chore(deps): update msrv (rust-lang/cargo#13266)
- refactor(toml): Make it more obvious to update package-dependent fields (rust-lang/cargo#13267)
- chore(ci): Fix MSRV:3 updates (rust-lang/cargo#13268)
- chore(ci): Shot-in-the-dark fix for MSRV updating (rust-lang/cargo#13265)
- fix: set OUT_DIR for all units with build scripts (rust-lang/cargo#13204)
- fix(manifest): Provide unused key warnings for lints table (rust-lang/cargo#13262)
- test(manifest): Verify we warn on unused workspace.package fields (rust-lang/cargo#13263)
- docs(changelog): Call out cargo-new lockfile change (rust-lang/cargo#13260)
- chore: Add dependency dashboard (rust-lang/cargo#13255)
r? ghost
Extend `useless_asref` lint on `map(clone)`
If you have code like:
```rust
Some(String::new()).as_ref().map(Clone::clone)
```
the `as_ref` call is unneeded.
Interestingly enough, this lint and `map_clone` are starting to share a same "space" where both lints warn about different things for the same code. Not sure what's the policy about such cases though...
r? `@llogiq`
changelog: Extend `useless_asref` lint on `map(clone)`
This removes emit_enum_variant and the emit_usize calls that resulted
in. In libcore this eliminates 17% of leb128, taking us from 8964488 to
7383842 leb128's serialized.
100% of the serialized enums during libcore compilation fit into the
smaller tag, and this eliminates hitting the leb128 code for
coding/decoding when we can statically guarantee that's not required.
30% of all leb128 integers serialized in libcore (12981183 total) come
from the usize's removed here.
Avoid silencing relevant follow-up errors
r? `@matthewjasper`
This PR only adds new errors to tests that are already failing and fixes one ICE.
Several tests were changed to not emit new errors. I believe all of them were faulty tests, and not explicitly testing for the code that had new errors.
A more efficient slice comparison implementation for T: !BytewiseEq
(This is a follow up PR on #113654)
This PR changes the implementation for `[T]` slice comparison when `T: !BytewiseEq`. The previous implementation using zip was not optimized properly by the compiler, which didn't leverage the fact that both length were equal. Performance improvements are for example 20% when testing that `[Some(0_u64); 4096].as_slice() == [Some(0_u64); 4096].as_slice()`.
This lets us avoid the use of `DiagnosticBuilder::into_diagnostic` in
miri, when then means that `DiagnosticBuilder::into_diagnostic` can
become private, being now only used by `stash` and `buffer`.
In #119606 I added them and used a `_mv` suffix, but that wasn't great.
A `with_` prefix has three different existing uses.
- Constructors, e.g. `Vec::with_capacity`.
- Wrappers that provide an environment to execute some code, e.g.
`with_session_globals`.
- Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`.
The third case is exactly what we want, so this commit changes
`DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`.
Thanks to @compiler-errors for the suggestion.
In #119606 I added them and used a `_mv` suffix, but that wasn't great.
A `with_` prefix has three different existing uses.
- Constructors, e.g. `Vec::with_capacity`.
- Wrappers that provide an environment to execute some code, e.g.
`with_session_globals`.
- Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`.
The third case is exactly what we want, so this commit changes
`DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`.
Thanks to @compiler-errors for the suggestion.
We have `span_delayed_bug` and often pass it a `DUMMY_SP`. This commit
adds `delayed_bug`, which matches pairs like `err`/`span_err` and
`warn`/`span_warn`.
- `struct_foo` + `emit` -> `foo`
- `create_foo` + `emit` -> `emit_foo`
I have made recent commits in other PRs that have removed some of these
shortcuts for combinations with few uses, e.g.
`struct_span_err_with_code`. But for the remaining combinations that
have high levels of use, we might as well use them wherever possible.
Because it takes an error code after the span. This avoids the confusing
overlap with the `DiagCtxt::struct_span_err` method, which doesn't take
an error code.
`~const` trait and projection bounds do not imply their non-const counterparts
This PR removes the hack where we install a non-const trait and projection bound for every `const_trait` and `~const` projection bound we have in the AST. It ends up messing up more things than it fixes, see words below.
Fixes#119718
cc `@fmease` `@fee1-dead` `@oli-obk`
r? fee1-dead or one of y'all i don't care
---
My understanding is that this hack was added to support the following code:
```rust
pub trait Owo<X = <Self as Uwu>::T> {}
#[const_trait]
pub trait Uwu: Owo {}
```
Which is concretely lifted from in the `FromResidual` and `Try` traits. Since within the param-env of `trait Uwu`, we only know that `Self: ~const Uwu` and not `Self: Uwu`, the projection `<Self as Uwu>::T` is not satsifyable.
This causes problems such as #119718, since instantiations of `FnDef` types coming from `const fn` really do **only** implement one of `FnOnce` or `const FnOnce`!
---
In the long-term, I believe that such code should really look something more like:
```rust
#[const_trait]
pub trait Owo<X = <Self as ~const Uwu>::T> {}
#[const_trait]
pub trait Uwu: Owo {}
```
... and that we should introduce some sort of `<T as ~const Foo>::Bar` bound syntax, since due to the fact that `~const` bounds can be present in item bounds, e.g.
```rust
#[const_trait] trait Foo { type Bar: ~const Destruct; }
```
It's easy to see that `<T as Foo>::Bar` and `<T as ~const Foo>::Bar` (or `<T as const Foo>::Bar`) can be distinct types with distinct item bounds!
**Admission**: I know I've said before that I don't like `~const` projection syntax, I do at this point believe they're necessary to fully express bounds and types in a maybe-const world.
Making `User<T>` and `User<[T]>` `Send`
All `User` types in SGX point to owned memory in userspace. Special care is always needed when accessing this memory as it must be assumed that an attacker is always able to change its content. Therefore, we can also easily transfer this memory between thread boundaries.
cc: ``@mzohreva`` ``@vn971`` ``@belalH`` ``@jethrogb``
