Embed length of offset/position into Span tag byte
This cuts the average bytes/relative span from 3.5 to 3.2 on libcore, ultimately saving ~400kb of data.
Rollup of 9 pull requests
Successful merges:
- #121065 (Add basic i18n guidance for `Display`)
- #121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check)
- #121829 (Dummy tweaks (attempt 2))
- #121857 (Implement async closure signature deduction)
- #121894 (const_eval_select: make it safe but be careful with what we expose on stable for now)
- #122014 (Change some attributes to only_local.)
- #122016 (will_wake tests fail on Miri and that is expected)
- #122018 (only set noalias on Box with the global allocator)
- #122028 (Remove some dead code)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 8 pull requests
Successful merges:
- #121202 (Limit the number of names and values in check-cfg diagnostics)
- #121301 (errors: share `SilentEmitter` between rustc and rustfmt)
- #121658 (Hint user to update nightly on ICEs produced from outdated nightly)
- #121846 (only compare ambiguity item that have hard error)
- #121961 (add test for #78894#71450)
- #121975 (hir_analysis: enums return `None` in `find_field`)
- #121978 (Fix duplicated path in the "not found dylib" error)
- #121991 (Merge impl_trait_in_assoc_types_defined_by query back into `opaque_types_defined_by`)
r? `@ghost`
`@rustbot` modify labels: rollup
only set noalias on Box with the global allocator
As discovered in https://github.com/rust-lang/miri/issues/3341, `noalias` and custom allocators don't go well together.
rustc can now check whether a Box uses the global allocator. This replaces the previous ad-hoc and rather unprincipled check for a zero-sized allocator.
This is the rustc part of fixing that; Miri will also need a patch.
const_eval_select: make it safe but be careful with what we expose on stable for now
As this is all still nightly-only I think `````@rust-lang/wg-const-eval````` can do that without involving t-lang.
r? `````@oli-obk`````
Cc `````@Nilstrieb````` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`
Implement async closure signature deduction
Self-explanatory from title.
Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:
1. async closures are unstable, and
2. I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).
This is in contrast to #109338, which was closed because it generalizes signature deduction for a *stable* kind of expression (`async {}` blocks and `Future` traits), and which proliferated usage may pose a stabilization hazard for the new solver.
I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc `````@lcnr`````
r? `````@oli-obk`````
Stop using Bubble in coherence and instead emulate it with an intercrate check
r? `````@compiler-errors`````
This change is kinda funny, because all I've done is reimplement `Bubble` behaviour for coherence without using `Bubble` explicitly.
Merge impl_trait_in_assoc_types_defined_by query back into `opaque_types_defined_by`
Instead, when we're collecting opaques for associated items, we choose the right collection mode depending on whether we're collecting for an associated item of a trait impl or not.
r? ```@compiler-errors```
follow up to https://github.com/rust-lang/rust/pull/121838
Fix duplicated path in the "not found dylib" error
While working on the gcc backend, I couldn't figure out why I had this error:
```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```
As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).
Thanks to `````@bjorn3````` for linking me to https://github.com/rust-lang/rust/pull/121392. :)
hir_analysis: enums return `None` in `find_field`
Fixes#121757.
Unnamed union fields with enums are checked for, but if `find_field` causes an ICE then the compiler won't get to that point.
Hint user to update nightly on ICEs produced from outdated nightly
This is a conservative best-effort approach to detect a potentially outdated nightly; it will fallback to the regular ICE-reporting if any of the following cases are true:
- Channel is not nightly
- Version information is not available
- Version date is not parseable as a YYYY-MM-DD or is missing
- System time is at least 36 hours ahead of the user's nightly release datetime.
- Any internal features are used.
Note that I'm not sure how to make a test for this: I tested this manually by `CFG_VER_DATE="2020-02-02" ./x build library --stage 1`, and also changing the channel detection in `rustc_driver_impl` from `Some("nightly")` to `Some("nightly" | "dev")`, and then running `rustc +stage1 test.rs -Ztreat-err-as-bug=1` with a non-existent `test.rs`.
<img width="1145" alt="Screenshot 2024-02-27 at 01 12 28" src="https://github.com/rust-lang/rust/assets/39484203/eff6af2e-4b19-4a70-af57-cd739ecf0e84">
Closes#118832.
errors: share `SilentEmitter` between rustc and rustfmt
Fixesrust-lang/rustfmt#6082.
Shares the `SilentEmitter` between rustc and rustfmt, and gives it a fallback bundle (since it can emit diagnostics in some contexts).
Limit the number of names and values in check-cfg diagnostics
The Rust for Linux [feedback](https://github.com/rust-lang/rust/issues/82450#issuecomment-1947462977) to the check-cfg Call for Testing, revealed a weakness in the check-cfg. They are unbounded and in the case RfL they have ~20k cfgs and having them printed (even once) is unbearable.
This PR limits it to 35 (28 rustc well known + `feature` + `docsrs` + 5 custom) which feels like a good middle ground for regular users (i.e. Cargo users).
When it goes over that limit print the N first with " and X more".
``@rustbot`` label +F-check-cfg
Instead, when we're collecting opaques for associated items, we choose the right collection mode depending on whether we're collecting for an associated item of a trait impl or not.
This is the short description (`64-bit MinGW (Windows 7+)`) including
the platform requirements.
The reason for doing it like this is that this PR will be quite prone to
conflicts whenever targets get added, so it should be as simple as
possible to get it merged. Future PRs which migrate targets are scoped
to groups of targets, so they will not conflict as they can just touch
these.
This moves some of the information from the rustc book into the
compiler.
It cannot be queried yet, that is future work. It is also future work to
fill out all the descriptions, which will coincide with the work of
moving over existing target docs to the new format.
interpret/cast: make more matches on FloatTy properly exhaustive
Actually implementing these is pretty trivial (at least once all the scalar methods are added, which happens in https://github.com/rust-lang/rust/pull/121926), but I'm staying consistent with the other f16/f128 PRs. Also adding adding all the tests to Miri would be quite a lot of work.
There's probably some way to reduce the code duplication here with more use of generics... but that's a future refactor.^^
r? ```@tgross35```
pattern analysis: abort on arity mismatch
This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](https://github.com/rust-lang/rust-analyzer/issues/16746)).
r? ```@compiler-errors```
Use the correct logic for nested impl trait in assoc types
Previously we accidentally continued with the TAIT visitor, which allowed more than we wanted to.
r? ```@compiler-errors```
Use root obligation on E0277 for some cases
When encountering trait bound errors that satisfy some heuristics that tell us that the relevant trait for the user comes from the root obligation and not the current obligation, we use the root predicate for the main message.
This allows to talk about "X doesn't implement Pattern<'_>" over the most specific case that just happened to fail, like "char doesn't implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`
The heuristics are:
- the type of the leaf predicate is (roughly) the same as the type from the root predicate, as a proxy for "we care about the root"
- the leaf trait and the root trait are different, so as to avoid talking about `&mut T: Trait` and instead remain talking about `T: Trait` instead
- the root trait is not `Unsize`, as to avoid talking about it in `tests/ui/coercion/coerce-issue-49593-box-never.rs`.
```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
--> $DIR/root-obligation.rs:6:38
|
LL | .filter(|c| "aeiou".contains(c))
| -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
| |
| required by a bound introduced by this call
|
= note: required for `&char` to implement `FnOnce<(char,)>`
= note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
--> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
|
LL | .filter(|c| "aeiou".contains(*c))
| +
```
Fix#79359, fix#119983, fix#118779, cc #118415 (the suggestion needs to change), cc #121398 (doesn't fix the underlying issue).
Adjust error `yield`/`await` lowering
Adjust the lowering of `yield`/`await` outside of their correct scopes so that we no longer make orpan HIR exprs.
Previously, `yield EXPR` would be lowered directly to `hir::TyKind::Error` (which I'll call `<error>`) which means that `EXPR` was not present in the HIR, but now we lower it to `{ EXPR; <error> }` so that `EXPR` is not orphaned.
Fixes#121096
They are two different ways of creating dummy results, with two
different purposes. Their implementations are separate except for
crates, where `DummyResult` depends on `DummyAstNode`.
This commit removes that dependency, so they are now fully separate. It
also expands the comment on `DummyAstNode`.
