rustc_session: Address all `rustc::potential_query_instability` lints
Instead of allowing `rustc::potential_query_instability` on the whole crate we go over each lint and allow it individually if it is safe to do. Turns out all instances were safe to allow in this crate.
Part of #84447 which is **E-help-wanted**.
coverage: Skip spans that can't be un-expanded back to the function body
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.
---
Extracted from #118305, since this is a general improvement that isn't specific to branch coverage.
---
`@rustbot` label +A-code-coverage
[rustdoc] Add highlighting for comments in items declaration
Fixes#117555.
So after the discussion in https://github.com/rust-lang/rust/pull/117643, the outcome was that having the comments in the item declaration at the same level (in term of color) as the rest of the code was actually a bit distracting and could be improved.
The current highlighting color for comments is "lighter" than the rest and I think it fits perfectly to improve the current situation. With this, we now have different "levels" which makes it easier to read and filter out what we want when reading the items declaration.
Here's a screenshot:
r? `@notriddle`
Provide structured suggestion for type mismatch in loop
We currently provide only a `help` message, this PR introduces the last two structured suggestions instead:
```
error[E0308]: mismatched types
--> $DIR/issue-98982.rs:2:5
|
LL | fn foo() -> i32 {
| --- expected `i32` because of return type
LL | / for i in 0..0 {
LL | | return i;
LL | | }
| |_____^ expected `i32`, found `()`
|
note: the function expects a value to always be returned, but loops might run zero times
--> $DIR/issue-98982.rs:2:5
|
LL | for i in 0..0 {
| ^^^^^^^^^^^^^ this might have zero elements to iterate on
LL | return i;
| -------- if the loop doesn't execute, this value would never get returned
help: return a value for the case when the loop has zero elements to iterate on
|
LL ~ }
LL ~ /* `i32` value */
|
help: otherwise consider changing the return type to account for that possibility
|
LL ~ fn foo() -> Option<i32> {
LL | for i in 0..0 {
LL ~ return Some(i);
LL ~ }
LL ~ None
|
```
Fix#98982.
SIMD bitmasks: use 'round up to multiple of 8' rather than 'clamp to at least 8'
This should prepare us better for a future with non-power-of-2 vectors, if they ever happen.
Report errors in jobserver inherited through environment variables
This pr attempts to catch situations, when jobserver exists, but is not being inherited.
r? `@petrochenkov`
Instead of allowing `rustc::potential_query_instability` on the whole
crate we go over each lint and allow it individually if it is safe to
do. Turns out all instances were safe to allow in this crate.
`DefPathData::(ClosureExpr,ImplTrait)` are renamed to match `DefKind::(Closure,OpaqueTy)`.
`DefPathData::ImplTraitAssocTy` is replaced with `DefPathData::TypeNS(kw::Empty)` because both correspond to `DefKind::AssocTy`.
It's possible that introducing `(DefKind,DefPathData)::AssocOpaqueTy` could be a better solution, but that would be a much more invasive change.
Const generic parameters introduced for effects are moved from `DefPathData::TypeNS` to `DefPathData::ValueNS`, because constants are values.
`DefPathData` is no longer passed to `create_def` functions to avoid redundancy.
Because a macro invocation can expand to a never pattern, we can't rule
out a `arm!(),` arm at parse time. Instead we detect that case at
expansion time, if the macro tries to output a pattern followed by `=>`.
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.
