This is weird: `HandlerInner::emit` calls
`HandlerInner::emit_diagnostic`, but only after doing a
`treat-err-as-bug` check. Which is fine, *except* that there are
multiple others paths for an `Error` or `Fatal` diagnostic to be passed
to `HandlerInner::emit_diagnostic` without going through
`HandlerInner::emit`, e.g. `Handler::span_err` call
`Handler::emit_diag_at_span`, which calls `emit_diagnostic`.
So that suggests that the coverage for `treat-err-as-bug` is incomplete.
This commit removes `HandlerInner::emit` and moves the
`treat-err-as-bug` check to `HandlerInner::emit_diagnostic`, so it
cannot by bypassed.
`Handler` is a wrapper around `HanderInner`. Some functions on
on `Handler` just forward to the samed-named functions on
`HandlerInner`.
This commit removes as many of those as possible, implementing functions
on `Handler` where possible, to avoid the boilerplate required for
forwarding. The commit is moderately large but it's very mechanical.
These impls are all needed for just a single `IntoDiagnostic` type, not
a family of them.
Note that `ErrorGuaranteed` is the default type parameter for
`IntoDiagnostic`.
Currently, `Handler::fatal` returns `FatalError`. But `Session::fatal`
returns `!`, because it calls `Handler::fatal` and then calls `raise` on
the result. This inconsistency is unfortunate.
This commit changes `Handler::fatal` to do the `raise` itself, changing
its return type to `!`. This is safe because there are only two calls to
`Handler::fatal`, one in `rustc_session` and one in
`rustc_codegen_cranelift`, and they both call `raise` on the result.
`HandlerInner::fatal` still returns `FatalError`, so I renamed it
`fatal_no_raise` to emphasise the return type difference.
move exposed-provenance APIs into separate feature gate
We have already stated explicitly for all the 'exposed' functions that
> Using this method means that code is *not* following strict provenance rules.
However, they were part of the same feature gate and still described as part of the strict provenance experiment. Unfortunately, their semantics are much less clear and certainly nowhere near stabilization, so in preparation for an attempt to stabilize the strict provenance APIs, I suggest we split the things related to "exposed" into their own feature gate. I also used this opportunity to better explain how Exposed Provenance fits into the larger plan here: this is *one possible candidate* for `as` semantics, but we don't know if it is actually viable, so we can't really promise that it is equivalent to `as`. If it works out we probably want to make `as` equivalent to the 'exposed' APIs; if it doesn't, we will remove them again and try to find some other semantics for `as`.
Update cargo
27 commits in 26333c732095d207aa05932ce863d850fb309386..623b788496b3e51dc2f9282373cf0f6971a229b5
2023-11-28 20:07:39 +0000 to 2023-12-02 18:10:03 +0000
- docs(book): make old title anchorable (rust-lang/cargo#13102)
- Revert "chore(deps): update rust crate openssl to 0.10.60 [security]" (rust-lang/cargo#13101)
- test(install): use TCP connection instead of thread sleep (rust-lang/cargo#13099)
- test(mdman): Switch to snapbox (rust-lang/cargo#13098)
- Include declared list of features in fingerprint for `-Zcheck-cfg` (rust-lang/cargo#13012)
- chore(deps): update compatible (rust-lang/cargo#13083)
- chore(ci): Always update gix packages together (rust-lang/cargo#13093)
- chore(deps): update rust crate windows-sys to 0.52 (rust-lang/cargo#13089)
- refactor(toml): Decouple logic from schema (rust-lang/cargo#13080)
- Have cargo add --optional <dep> create a <dep> = "dep:<dep> feature (rust-lang/cargo#13071)
- Add `--public` for `cargo add` (rust-lang/cargo#13046)
- chore(deps): update rust crate toml_edit to 0.21.0 (rust-lang/cargo#13088)
- chore(deps): update rust crate rusqlite to 0.30.0 (rust-lang/cargo#13087)
- test(trim-paths): exercise with real world debugger (rust-lang/cargo#13091)
- Fixed uninstall a running binary failed on Windows (rust-lang/cargo#13053)
- chore(deps): update rust crate itertools to 0.12.0 (rust-lang/cargo#13086)
- Add more options to registry test support. (rust-lang/cargo#13085)
- Don't filter on workspace members when scraping doc examples (rust-lang/cargo#13077)
- Remove the outdated comment (rust-lang/cargo#13076)
- fix(resolver): Remove unused public-deps error handling (rust-lang/cargo#13036)
- Fixes error count display is different when there's only one error left (rust-lang/cargo#12484)
- fix: reorder `--remap-path-prefix` flags for `-Zbuild-std` (rust-lang/cargo#13065)
- remove jobserver env var in some tests (rust-lang/cargo#13072)
- doc: clarify different target has different set of `CARGO_CFG_*` values (rust-lang/cargo#13069)
- docs: remove review capacity notice in PR template (rust-lang/cargo#13070)
- chore(deps): update rust crate openssl to 0.10.60 [security] (rust-lang/cargo#13068)
- fix(resolver): De-prioritize no-rust-version in MSRV resolver (rust-lang/cargo#13066)
Avoid per-register closure expansions
Best reviewed with whitespace ignored.
This hopefully reduces overall size of the binary. Probably zero impact in instructions/cycles in rustc-perf since we don't really have any asm benchmarks AFAIK...
Add substring API for `OsStr`
This adds a method for taking a substring of an `OsStr`, which in combination with [`OsStr::as_encoded_bytes()`](https://doc.rust-lang.org/std/ffi/struct.OsStr.html#method.as_encoded_bytes) makes it possible to implement most string operations in safe code.
API:
```rust
impl OsStr {
pub fn slice_encoded_bytes<R: ops::RangeBounds<usize>>(&self, range: R) -> &Self;
}
```
Motivation, examples and research at https://github.com/rust-lang/libs-team/issues/306.
Tracking issue: #118485
cc `@epage`
r? libs-api
move packed-struct tests into packed/ folder
We already have a bunch of other tests named `packed/packed-struct*`, no reason to have these two tests be separate.
Add more information to StableMIR Instance
Allow stable MIR users to retrieve an instance function signature, the index for a VTable instance and more information about its underlying definition.
These are needed to properly interpret function calls, either via VTable or direct calls. The `CrateDef` implementation will also allow users to emit diagnostic messages.
I also fixed a few issues that we had identified before with how we were retrieving body of things that may not have a body available.
Handle recursion limit for subtype and well-formed predicates
Adds a recursion limit check for subtype predicates and well-formed predicates.
`-Ztrait-solver=next` currently panics with unimplemented for these cases.
These cases are arguably bugs in the occurs check but:
- I could not find a simple way to fix the occurs check
- There should still be a recursion limit check to prevent hangs anyway.
closes#117151
r? types
Centralize live loans maintenance to fix scope differences due to liveness
As found in the recent [polonius crater run](https://github.com/rust-lang/rust/pull/117593#issuecomment-1801398892), NLLs and the location-insensitive polonius computed different scopes on some specific CFG shapes, e.g. the following.
I had missed that liveness data was pushed from different sources than just the liveness computation: there are a few places that do this -- and some of them may be unneeded or at the very least untested, as no tests changed when I tried removing some of them.
Here, `_6` is e.g. dead on entry to `bb2[0]` during `liveness::trace`, but its regions will be marked as live later during "constraint generation" (which I plan to refactor away and put in the liveness module soon). This should cause the inflowing loans to be marked live, but they were only computed in `liveness::trace`.
Therefore, this PR moves live loan maintenance to `LivenessValues`, so that the various places pushing liveness data will all also update live loans at the same time -- except for promoteds which I don't believe need them, and their liveness handling is already interesting/peculiar.
All the regressions I saw in the initial crater run were related to this kind of shapes, and this change did fix all of them on the [next run](https://github.com/rust-lang/rust/pull/117593#issuecomment-1826132145).
r? `@matthewjasper`
(This will conflict with #117880 but whichever lands first is fine by me, the end goal is the same for both)
Nicholas Nethercote