Remove `//@ compare-output-lines-by-subset`
There was only ever one test which used this flag, and it was removed in https://github.com/rust-lang/rust/pull/132244. I think this is a bad flag that should never have been added; comparing by subset makes the test failures extremely hard to debug. Any test that needs complicated output filtering like this should just use run-make instead.
Note that this does not remove the underlying comparison code, because it's still used if `runner` is set. I don't quite understand what's going on there, but since we still test on other platforms and in CI that the full output is accurate, I think it will be easier to debug than a test that uses compare-by-subset unconditionally.
rustc-dev-guide update PR: https://github.com/rust-lang/rustc-dev-guide/pull/2151
rustdoc-json: Include safety of `static`s
`static`s in an `extern` block can have an associated safety annotation ["because there is nothing guaranteeing that the bit pattern at the static’s memory is valid for the type it is declared with"](https://doc.rust-lang.org/reference/items/external-blocks.html#statics). Rustdoc already knows this and displays in for HTML. This PR also includes it in JSON.
Inspired by https://github.com/obi1kenobi/cargo-semver-checks/issues/975 which needs this, but it's probably useful in other places.
r? `@GuillaumeGomez.` Possibly easier to review commit-by-commit.
Eliminate magic numbers from expression precedence
Context: see https://github.com/rust-lang/rust/pull/133140.
This PR continues on backporting Syn's expression precedence design into rustc. Rustc's design used mysterious integer quantities represented variously as `i8` or `usize` (e.g. `PREC_CLOSURE = -40i8`), a special significance around `0` that is never named, and an extra `PREC_FORCE_PAREN` precedence level that does not correspond to any expression. Syn's design uses a C-like enum with variants that clearly correspond to specific sets of expression kinds.
This PR is a refactoring that has no intended behavior change on its own, but it unblocks other precedence work that rustc's precedence design was poorly suited to accommodate.
- Asymmetrical precedence, so that a pretty-printer can tell `(return 1) + 1` needs parens but `1 + return 1` does not.
- Squashing the `Closure` and `Jump` cases into a single precedence level.
- Numerous remaining false positives and false negatives in rustc pretty-printer's parenthesization of macro metavariables, for example in `$e < rhs` where $e is `lhs as Thing<T>`.
FYI `@fmease` — you don't need to review if rustbot picks someone else, but you mentioned being interested in the followup PRs.
Rollup of 5 pull requests
Successful merges:
- #131416 (Mark `slice::copy_from_slice` unstably const)
- #131784 (Stabilize unsigned and float variants of `num_midpoint` feature)
- #133446 (coverage: Use a query to identify which counter/expression IDs are used)
- #133711 (add isatty doc alias for `is_terminal`)
- #133712 (rust_analyzer_settings: force use of 'nightly' toolchain)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `hir::ArrayLen`
This refactoring removes `hir::ArrayLen`, replacing it with `hir::ConstArg`. To represent inferred array lengths (previously `hir::ArrayLen::Infer`), a new variant `ConstArgKind::Infer` is added.
r? `@BoxyUwU`
There was only ever one test which used this flag, and it was removed in https://github.com/rust-lang/rust/pull/132244. I think this is a bad flag that should never have been added; comparing by subset makes the test failures extremely hard to debug. Any test that needs complicated output filtering like this should just use run-make instead.
Note that this does not remove the underlying comparison code, because it's still used if `runner` is set. I don't quite understand what's going on there, but since we still test on other platforms and in CI that the full output is accurate, I think it will be easier to debug than a test that uses compare-by-subset unconditionally.
rust_analyzer_settings: force use of 'nightly' toolchain
The cranelift folder contains a rust-toolchain file. That means when RA opens `compiler/rustc_codegen_cranelift/Cargo.toml`, it will try to use that toolchain or fail. (Maybe that toolchain gets auto-installed for others? On my system, it just fails, but I also run vscodium in a sandbox.)
However, it shouldn't be necessary to use more than one toolchain for the rustc workspace. So we can set the `RUSTUP_TOOLCHAIN` variable on the server side to force the same toolchain to be used everywhere.
Suggested by `@ChayimFriedman2` in https://github.com/rust-lang/rust-analyzer/issues/18585.
add isatty doc alias for `is_terminal`
(first Rust contribution!)
This adds `isatty` as a doc alias for [`std::io::IsTerminal::is_terminal`](https://doc.rust-lang.org/stable/std/io/trait.IsTerminal.html#tymethod.is_terminal).
I think this change does meet the [doc alias policy](https://std-dev-guide.rust-lang.org/policy/doc-alias.html). This would be especially useful because searching "rust isatty" gets you the `isatty` crate which is deprecated in favor of `atty`. `atty` is unmaintained and you might get to `is-terminal`, which will finally tell you that the function you're looking for has been in `std` all along.
The Windows implementation of `is_terminal()` doesn't use `isatty`, but that hasn't been a problem for the analogous cases of `create_dir()`'s alias `mkdir` or `remove_dir()`/`rmdir`.
coverage: Use a query to identify which counter/expression IDs are used
Given that we already have a query to identify the highest-numbered counter ID in a MIR body, we can extend that query to also build bitsets of used counter/expression IDs. That lets us avoid some messy coverage bookkeeping during the main MIR traversal for codegen.
This does mean that we fail to treat some IDs as used in certain MIR-inlining scenarios, but I think that's fine, because it means that the results will be consistent across all instantiations of a function.
---
There's some more cleanup I want to do in the function coverage collector, since it isn't really collecting anything any more, but I'll leave that for future work.
Stabilize unsigned and float variants of `num_midpoint` feature
This PR proposes that we stabilize the unsigned variants of the [`num_midpoint`](https://github.com/rust-lang/rust/issues/110840#issue-1684506201) feature as well as the floats variants, since they are not subject to any unresolved questions, which is equivalent to doing `(a + b) / 2` (and `(a + b) >> 1`) in a sufficiently large number.
The stabilized API surface would be:
```rust
/// Calculates the middle point of `self` and `rhs`.
///
/// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a sufficiently-large unsigned integral type.
/// This implies that the result is always rounded towards negative infinity and that no overflow will ever occur.
impl u{8,16,32,64,128,size} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
impl NonZeroU{8,16,32,64,size} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
impl f{32,64} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
```
The signed variants `u{8,16,32,64,128,size}` would remain gated, until a decision is made about the rounding mode, in other words that the [unresolved questions](https://github.com/rust-lang/rust/issues/110840#issue-1684506201) are resolved.
cc `@rust-lang/libs-api`
cc `@scottmcm`
r? libs-api
Mark `slice::copy_from_slice` unstably const
Tracking issue #131415
I used `const_eval_select` for runtime and const panic functions because const formatting isn't available yet.
Stop cloning `Context` so much
This is a first step for https://github.com/rust-lang/rust/issues/82381.
It's already big enough so I'll continue in a follow-up once this PR is merged. Next step will be to get rid of `SharedContext` by inlining it directly into `Context`.
cc `@camelid`
r? `@notriddle`
Rollup of 7 pull requests
Successful merges:
- #132974 (Properly pass linker arguments that contain commas)
- #133403 (Make `adjust_fulfillment_errors` work with `HostEffectPredicate` and `const_conditions`)
- #133482 (Only error raw lifetime followed by `\'` in edition 2021+)
- #133595 (Do not emit `missing_doc_code_examples` rustdoc lint on module and a few other items)
- #133669 (Move some functions out of const_swap feature gate)
- #133674 (Fix chaining `carrying_add`s)
- #133691 (Check let source before suggesting annotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not emit `missing_doc_code_examples` rustdoc lint on module and a few other items
It doesn't make sense to expect modules to have code examples. Same goes for:
* Trait aliases
* Foreign items
* Associated types and constants
Should make the use of this lint a bit nicer.
r? ``@notriddle``
Only error raw lifetime followed by `\'` in edition 2021+
Fixes#133479
cc #132341
I think this fixes a purely theoretical regression since it only affects edition 2015 (who is using that?) and only in the very rare case of a raw lifetime followed immediately by a lifetime like `'r#a'r`.
Make `adjust_fulfillment_errors` work with `HostEffectPredicate` and `const_conditions`
Greatly improves the spans for reporting unsatisfied `~const` bounds :)
r? project-const-traits or maybe ``@lcnr`` (if you want to deal with a diagnostics PR lmao)
Properly pass linker arguments that contain commas
When linking with the system C compiler, we sometimes want to forward certain arguments unchanged to the linker. This can be done with `-Wl,arg1,arg2` or `-Xlinker arg1 -Xlinker arg2`. `-Wl` is used when possible, since it is more compact, but it does not support commas in the argument itself - in those cases, we need to use `-Xlinker`, and that is what this PR implements.
This also fixes using sanitizers on macOS with `-Clinker-flavor=ld`, as those were previously manually using `-Wl`/`-Xlinker` (probably since the support wasn't present in the `link_args` function).
Note that there has been [a previous PR for this](https://github.com/rust-lang/rust/pull/38798), but it only implemented this in certain cases when passing `-rpath`.
r? compiler
Rollup of 8 pull requests
Successful merges:
- #128184 (std: refactor `pthread`-based synchronization)
- #132047 (Robustify and genericize return-type-notation resolution in `resolve_bound_vars`)
- #133515 (fix: hurd build, stat64.st_fsid was renamed to st_dev)
- #133602 (fix: fix codeblocks in `PathBuf` example)
- #133622 (update link to "C++ Exceptions under the hood" blog)
- #133660 (Do not create trait object type if missing associated types)
- #133686 (Add diagnostic item for `std::ops::ControlFlow`)
- #133689 (Fixed typos by changing `happend` to `happened`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add diagnostic item for `std::ops::ControlFlow`
This will be used in Clippy to detect useless conversions done through `ControlFlow::map_break()` and `ControlFlow::map_continue()`.
