Consider unfulfilled obligations in binop errors
When encountering a binop where the types would have been accepted, if
all the predicates had been fulfilled, include information about the
predicates and suggest appropriate `#[derive]`s if possible.
Fix#84515.
When encountering a binop where the types would have been accepted, if
all the predicates had been fulfilled, include information about the
predicates and suggest appropriate `#[derive]`s if possible.
Point at trait(s) that needs to be `impl`emented.
Rollup of 10 pull requests
Successful merges:
- #88706 (Normalize associated type projections when checking return type of main)
- #88828 (Use `libc::sigaction()` instead of `sys::signal()` to prevent a deadlock)
- #88871 (Fix suggestion for nested struct patterns)
- #89317 (Move generic error message to separate branches)
- #89351 (for signed wrapping remainder, do not compare lhs with MIN)
- #89442 (Add check for duplicated doc aliases)
- #89502 (Fix Lower/UpperExp formatting for integers and precision zero)
- #89523 (Make `proc_macro_derive_resolution_fallback` a future-breakage lint)
- #89532 (Document behavior of `MaybeLiveLocals` regarding enums and field-senstivity)
- #89546 (Make an initial guess for metadata size to reduce buffer resizes)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make an initial guess for metadata size to reduce buffer resizes
When reading metadata, the compiler starts with a `Vec::new()`, which will need to grow repeatedly as the metadata gets decompressed into it. Reduce the number of resizes by starting out at the size of the compressed data.
Document behavior of `MaybeLiveLocals` regarding enums and field-senstivity
This arose from a [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/MaybeLiveLocals.20and.20Discriminants) where a new contributor attempted to implement a dead-store elimination pass using this analysis. They ran into a nasty hack around `SetDiscriminant` the effect of which is to lets handle assignments of literals to enum-typed locals (e.g. `x = Some(4)`) correctly. This took me a while to figure out.
Document this oddity, so the next person will have an easier time, and add a test to enshrine the current behavior.
r? ``@tmiasko``
Make `proc_macro_derive_resolution_fallback` a future-breakage lint
When `cargo report future-incompatibilities` is stabilized
(see #71249), this will cause dependencies that trigger
this lint to be included in the report.
Fix Lower/UpperExp formatting for integers and precision zero
Fixes the integer part of #89493 (I daren't touch the floating-point formatting code). The issue is that the "subtracted" precision essentially behaves like extra trailing zeros, but this is not currently reflected in the code properly.
for signed wrapping remainder, do not compare lhs with MIN
Since the wrapped remainder is going to be 0 for all cases when the rhs is -1, there is no need to compare the lhs with MIN.
Move generic error message to separate branches
This decomposes an error message in generic constants into more specific branches, for better
readability.
r? ``@lcnr``
Normalize associated type projections when checking return type of main
This fixes#88609.
Previously, the return type of `fn main()` would not have any associated type projections within normalized before checking if it implements the standard library trait `std::process::Termination`. This commit appears to fix it.
This feels vaguely symptomatic of a problem in the underlying trait solving engine, but I am not sure how I would solve that. I am unsure why the example in #88609 with `assert_impl_termination` and `fn foo()` work, but simply `fn main()` doesn't. The way that I solved this is also probably not the best way to do this, so please let me know if there is a better way to do this.
I have added a build-pass regression test for this issue.
improved help message for `suspicious_map`
`suspicious_map`'s help message assumes that the literal behavior is never the intended one, although it's sometimes. This PR adds a mention of `inspect`, offering a idiomatic alternative.
fixes#7767
---
changelog: Improved help message of [`suspicious_map`].
Fixes#67007
Currently, a 'borrowed data escapes' error does not mention
the specific lifetime involved (except indirectly through a suggestion
about adding a lifetime bound). We now explain the specific lifetime
relationship that failed to hold, which improves otherwise vague
error messages.
Made the fields of VecDeque's IterMut private by creating a IterMut::new(...) function to create a new instance of IterMut and migrating usage to use IterMut::new(...).
By adding #![doc(cfg_hide(foobar))] to the crate attributes the cfg
#[cfg(foobar)] (and _only_ that _exact_ cfg) will not be implicitly
treated as a doc(cfg) to render a message in the documentation.
This is only active when the `doc_cfg` feature is active.
The implicit cfg can be overridden via #[doc(cfg(...))], so e.g. to
hide a #[cfg] you can use something like:
```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```
(since `all()` is always true, it is never shown in the docs)
No functional changes intended.
The LLVM commit
e463b69736
changed an argument of fatal_error_handler_t from std::string to char*.
This adapts RustWrapper accordingly.
Since the wrapped remainder is going to be 0 for all cases when the rhs is -1,
there is no need to divide in this case. Comparing the lhs with MIN is only done
for the overflow bool. In particular, this results in better code generation for
wrapping remainder, which discards the overflow bool completely.
Rollup of 12 pull requests
Successful merges:
- #87631 (os current_exe using same approach as linux to get always the full ab…)
- #88234 (rustdoc-json: Don't ignore impls for primitive types)
- #88651 (Use the 64b inner:monotonize() implementation not the 128b one for aarch64)
- #88816 (Rustdoc migrate to table so the gui can handle >2k constants)
- #89244 (refactor: VecDeques PairSlices fields to private)
- #89364 (rustdoc-json: Encode json files with UTF-8)
- #89423 (Fix ICE caused by non_exaustive_omitted_patterns struct lint)
- #89426 (bootstrap: add config option for nix patching)
- #89462 (haiku thread affinity build fix)
- #89482 (Follow the diagnostic output style guide)
- #89504 (Don't suggest replacing region with 'static in NLL)
- #89535 (fix busted JavaScript in error index generator)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix busted JavaScript in error index generator
The old JavaScript didn't work. It filled the browser console with "e.previousElementSibling not defined" errors, because it didn't account for the example-wrap div that a newer version of rustdoc added.
Additionally, it had copied versions of utility functions that had been optimized in rustdoc main.js. This version updates those.
Don't suggest replacing region with 'static in NLL
Fixes#73159
This is similar to #69350 - if the user didn't initially
write out a 'static lifetime, adding 'static in response to
a lifetime error is usually the wrong thing to do.
bootstrap: add config option for nix patching
On NixOS systems, bootstrap will patch rustc used in bootstrapping after checking `/etc/os-release` (to confirm the current distribution is NixOS). However, when using Nix on a non-NixOS system, it can be desirable for bootstrap to patch rustc. In this commit, a `patch-binaries-for-nix` option is added to `config.toml`, which allows for user opt-in to bootstrap's Nix patching.
r? ``@Mark-Simulacrum``
Fix ICE caused by non_exaustive_omitted_patterns struct lint
fixes#89382
Add check that a list of `Pat`s is non empty to prevent ICE in `FnCtxt::lint_non_exhaustive_omitted_patterns`.
Is related to #89374 and #89105
rustdoc-json: Encode json files with UTF-8
Currently, `check_missing_items.py` malfunctions when the index contains some letters like emojis.
Related to #89360.
refactor: VecDeques PairSlices fields to private
Reducing VecDeque's PairSlices fields to private, a `from(...)` method is already used to create PairSlices.
Use the 64b inner:monotonize() implementation not the 128b one for aarch64
aarch64 prior to v8.4 (FEAT_LSE2) doesn't have an instruction that guarantees
untorn 128b reads except for completing a 128b load/store exclusive pair
(ldxp/stxp) or compare-and-swap (casp) successfully. The requirement to
complete a 128b read+write atomic is actually more expensive and more unfair
than the previous implementation of monotonize() which used a Mutex on aarch64,
especially at large core counts. For aarch64 switch to the 64b atomic
implementation which is about 13x faster for a benchmark that involves many
calls to Instant::now().
Rollup of 15 pull requests
Successful merges:
- #87993 (Stabilize try_reserve)
- #88090 (Perform type inference in range pattern)
- #88780 (Added abs_diff for integer types.)
- #89270 (path.push() should work as expected on windows verbatim paths)
- #89413 (Correctly handle supertraits for min_specialization)
- #89456 (Update to the final LLVM 13.0.0 release)
- #89466 (Fix bug with query modifier parsing)
- #89473 (Fix extra `non_snake_case` warning for shorthand field bindings)
- #89474 (rustdoc: Improve doctest pass's name and module's name)
- #89478 (Fixed numerus of error message)
- #89480 (Add test for issue 89118.)
- #89487 (Try to recover from a `=>` -> `=` or `->` typo in a match arm)
- #89494 (Deny `where` clauses on `auto` traits)
- #89511 (⬆️ rust-analyzer)
- #89536 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup