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`.
When we extract coverage spans from MIR, we try to "un-expand" them back to
spans that are inside the function's body span.
In cases where that doesn't succeed, the current code just swaps in the entire
body span instead. But that tends to result in coverage spans that are
completely unrelated to the control flow of the affected code, so it's better
to just discard those spans.
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
The `library/std/src/sys_common/net.rs` module is intended to define
common implementations of networking-related APIs across a variety of
platforms that share similar APIs (e.g. Berkeley-style sockets and all).
This module is not included for more fringe targets however such as UEFI
or "unknown" targets to libstd (those classified as `restricted-std`).
Previously the `sys_common/net.rs` file was set up such that an
allow-list indicated it shouldn't be used. This commit inverts the logic
to have an allow-list of when it should be used instead.
The goal of this commit is to make it a bit easier to experiment with a
new Rust target. Currently more esoteric targets are required to get an
exception in this `cfg_if` block to use `crate::sys::net` such as for
unsupported targets. With this inversion of logic only targets which
actually support networking will be listed, where most of those are
lumped under `cfg(unix)`.
Given that this change is likely to cause some breakage for some target
by accident I've attempted to be somewhat robust with this by following
these steps to defining the new predicate for inverted logic.
1. Take all supported targets and filter out all `cfg(unix)` ones as
these should all support `sys_common/net.rs`.
2. Take remaining targets and filter out `cfg(windows)` ones.
3. The remaining dozen-or-so targets were all audited by hand. Mostly
this included `target_os = "hermit"` and `target_os = "solid_asp3"`
which required an allow-list entry, but remaining targets were all
already excluded (didn't use `sys_common/net.rs` so they were left
out.
If this causes breakage it should be relatively easy to fix and I'd be
happy to follow-up with any PRs necessary.
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)
