Suggest tuple-parentheses for enum variants
This follows on from #86493 / #86481, making the parentheses suggestion. To summarise, given the following code:
```rust
fn f() -> Option<(i32, i8)> {
Some(1, 2)
}
```
The current output is:
```
error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied
--> b.rs:2:5
|
2 | Some(1, 2)
| ^^^^ - - supplied 2 arguments
| |
| expected 1 argument
error: aborting due to previous error
For more information about this error, try `rustc --explain E0061`.
```
With this change, `rustc` will now suggest parentheses when:
- The callee is expecting a single tuple argument
- The number of arguments passed matches the element count in the above tuple
- The arguments' types match the tuple's fields
```
error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied
--> b.rs:2:5
|
2 | Some(1, 2)
| ^^^^ - - supplied 2 arguments
|
help: use parentheses to construct a tuple
|
2 | Some((1, 2))
| + +
```
Only traverse attrs once while checking for coherence override attributes
In coherence, while checking for negative impls override attributes: only traverse the `DefId`s' attributes once.
This PR is an easy way to get back some of the small perf loss in #93175
Clarify the `usage-of-qualified-ty` error message.
I found this message confusing when I encountered it. This commit makes
it clearer that you have to import the unqualified type yourself.
r? `@lcnr`
Introduce a limit to Levenshtein distance computation
Incorporate distance limit from `find_best_match_for_name` directly into
Levenshtein distance computation.
Use the string size difference as a lower bound on the distance and exit
early when it exceeds the specified limit.
After finding a candidate within a limit, lower the limit further to
restrict the search space.
Add test for stable hash uniqueness of adjacent field values
This PR adds a simple test to check that stable hash will produce a different hash if the order of two values that have the same combined bit pattern changes.
r? `@the8472`
Define c_char using cfg_if rather than repeating 40-line cfg
Libstd has a 40-line cfg that defines the targets on which `c_char` is unsigned, and then repeats the same cfg with `not(…)` for the targets on which `c_char` is signed.
This PR replaces it with a `cfg_if!` in which an `else` takes care of the signed case.
I confirmed that `x.py doc library/std` inlines the type alias because c_char_definition is not a publicly accessible path:
It's simply a binary thing to allow different behaviour for `Copy` vs
`!Copy` types. The new code makes this much clearer; I was scratching my
head over the old code for some time.
Ignore unwinding edges when checking for unconditional recursion
The unconditional recursion lint determines if all execution paths
eventually lead to a self-recursive call.
The implementation always follows unwinding edges which limits its
practical utility. For example, it would not lint function `f` because a
call to `g` might unwind. It also wouldn't lint function `h` because an
overflow check preceding the self-recursive call might unwind:
```rust
pub fn f() {
g();
f();
}
pub fn g() { /* ... */ }
pub fn h(a: usize) {
h(a + 1);
}
```
To avoid the issue, assume that terminators that might continue
execution along non-unwinding edges do so.
Fixes#78474.
Add x86_64-pc-windows-msvc linker-plugin-lto instructions
I had some trouble getting cross language LTO working for this target, in part because the very few links of documentation I could find were linux-centric and because of a few very specific errors I ran into. I'm not sure if this is the correct place to document this, but this is one of the first links I found when looking for documentation so it might be the best place for it.
add OpenBSD platform-support page
It mentions x86_64, i686, aarch64 and sparc64 which are actively maintained and used on OpenBSD (binaries provided by standard package distribution on OpenBSD).
I volontary kept `powerpc-unknown-openbsd` unmentioned as it was added by `@Yn0ga` in #82733, and I am unaware if it is functional or not (I doubt as I added libc support only few days ago, and std `c_char` signess was wrong). `@Yn0ga` maybe you comment on your `powerpc-unknown-openbsd` usage ?
Replace iterator-based construction of collections by `Into<T>`
Just a few quality of life improvements in the doc examples. I also removed some `Vec`s in favor of arrays.
Improve Duration::try_from_secs_f32/64 accuracy by directly processing exponent and mantissa
Closes: #90225
The methods now implement direct processing of exponent and mantissa, which should result in the best possible conversion accuracy (modulo truncation, i.e. float value of 19.995 ns will be represented as 19 ns).
The unconditional recursion lint determines if all execution paths
eventually lead to a self-recursive call.
The implementation always follows unwinding edges which limits its
practical utility. For example, it would not lint function `f` because a
call to `g` might unwind. It also wouldn't lint function `h` because an
overflow check preceding the self-recursive call might unwind:
```rust
pub fn f() {
g();
f();
}
pub fn g() { /* ... */ }
pub fn h(a: usize) {
h(a + 1);
}
```
To avoid the issue, assume that terminators that might continue
execution along non-unwinding edges do so.
Fix the unsoundness in the `early_otherwise_branch` mir opt pass
Closes#78496 .
This change is a significant rewrite of much of the pass. Exactly what it does is documented in the source file (with ascii art!), and all the changes that are made to the MIR that are not trivially sound are carefully documented. That being said, this is my first time touching MIR, so there are probably some invariants I did not know about that I broke.
This version of the optimization is also somewhat more flexible than the original; for example, we do not care how or where the value on which the parent is switching is computed. There is no requirement that any types be the same. This could be made even more flexible in the future by allowing a wider range of statements in the bodies of `BBC, BBD` (as long as they are all the same of course). This should be a good first step though.
Probably needs a perf run.
r? `@oli-obk` who reviewed things the last time this was touched
Incorporate distance limit from `find_best_match_for_name` directly into
Levenshtein distance computation.
Use the string size difference as a lower bound on the distance and exit
early when it exceeds the specified limit.
After finding a candidate within a limit, lower the limit further to
restrict the search space.
rustdoc: Pre-calculate traits that are in scope for doc links
This eliminates one more late use of resolver (part of #83761).
At early doc link resolution time we go through parent modules of items from the current crate, reexports of items from other crates, trait items, and impl items collected by `collect-intra-doc-links` pass, determine traits that are in scope in each such module, and put those traits into a map used by later rustdoc passes.
r? `@jyn514`
