Felix S. Klock II pointed out that this suggestion (introduced in
pull-request #43178 / eac74104) was being issued for one-field-struct
expected types (in which case it is misleading and outright wrong),
even though it was only intended for one-field enum-variants (most
notably, `Some`). Particularly tender-hearted code-historians may be
inclined to show mercy towards the author of #43178 on the grounds
that it's somewhat confusing that struct field definitions are given
in a type called `ty::VariantDef`.
Add a conditional to adhere to the original intent. (It would be
possible to generalize to structs, but not obviously net desirable.)
This adds a level of indentation, so the diff here is going to be
easier to read in ignore-whitespace mode (`-w`).
Resolves#55250.
The example was not as clear as it could be because it was making an assumption about the structure of the data in order to multiply the number of collection elements by the item size. This change demonstrates the idea more straightforwardly, without the calculation.
Changes:
````
new_ret_no_self: add sample from #3313 to Known Problems section.
Support multiline comments and hopefully fix panic
Check for comments in collapsible ifs
Resolve ICE in needless range loop lint
RIIR update_lints: Update changelog links
Rename if_let_redundant_pattern_matching to redundant_pattern_matching
Add lint for redundant pattern matching for explicit return boolean
Fix issue #3322: reword help message for len_zero
Simplify manual_memcpy suggestion in some cases
Fix dogfood
Update known problems for unnecessary_fold
RIIR update_lints: Replace lint count in README.md
Rename `active_lints` to `usable_lints`
Add comment on WalkDir vs. fs::read_dir
sort_by -> sort_by_key
Some more documentation for clippy_dev
Use `WalkDir` to also gather from subdirectories
Avoid linting `boxed_local` on trait implementations.
Website: Make lint categories linkable
Restore clippy_dummy's placeholder name
Swap order of methods in `needless_range_loop` suggestion in some cases
Revert "Exclude pattern guards from unnecessary_fold lint"
Exclude pattern guards from unnecessary_fold lint
````
[NLL] Use new region infer errors when explaining borrows
Use the new free region infer errors for explaining borrows
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure to a captured variable. (E0521)
Closes#51026 - `regions-nested-fns-2.rs` isn't changed to that diagnostic, since that would not be the correct error here.
Closes#51169
cc #53882 - The error is (IMO) better now, but it could be better when we trace lifetimes in these error messages.
r? @nikomatsakis cc @pnkfelix
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value
referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure
to a captured variable.
Update Cargo, build curl/OpenSSL statically via features
In addition to to updating Cargo's submodule and Cargo's dependencies,
this also updates Cargo's build to build OpenSSL statically into Cargo
as well as libcurl unconditionally. This removes OpenSSL build logic
from the bootstrap code, and otherwise requests that even on OSX we
build curl statically.
In addition to to updating Cargo's submodule and Cargo's dependencies,
this also updates Cargo's build to build OpenSSL statically into Cargo
as well as libcurl unconditionally. This removes OpenSSL build logic
from the bootstrap code, and otherwise requests that even on OSX we
build curl statically.
Rollup of 5 pull requests
Successful merges:
- #55156 (Fixed: Multiple errors on single typo in match pattern)
- #55189 (update books for the next release)
- #55193 (make asm diagnostic instruction optional)
- #55203 (Write an initial version of the `program_clauses` callback)
- #55213 (ignore target folders)
Failed merges:
r? @ghost
Adds UseAsConst and UseAsStatic to replace Return in consts/statics.
Don't report the arguments to an overloaded operator as CallArguments.
Also don't report "escaping data" in these items.
when you try to edit a crate inside the compiler tree using rls, it
generates it's assets under target/rls, then tidy is trying to validate
line lenghts for C headers, etc
The issue of passing around SIMD types as values between functions has
seen [quite a lot] of [discussion], and although we thought [we fixed
it][quite a lot] it [wasn't]! This PR is a change to rustc to, again,
try to fix this issue.
The fundamental problem here remains the same, if a SIMD vector argument
is passed by-value in LLVM's function type, then if the caller and
callee disagree on target features a miscompile happens. We solve this
by never passing SIMD vectors by-value, but LLVM will still thwart us
with its argument promotion pass to promote by-ref SIMD arguments to
by-val SIMD arguments.
This commit is an attempt to thwart LLVM thwarting us. We, just before
codegen, will take yet another look at the LLVM module and demote any
by-value SIMD arguments we see. This is a very manual attempt by us to
ensure the codegen for a module keeps working, and it unfortunately is
likely producing suboptimal code, even in release mode. The saving grace
for this, in theory, is that if SIMD types are passed by-value across
a boundary in release mode it's pretty unlikely to be performance
sensitive (as it's already doing a load/store, and otherwise
perf-sensitive bits should be inlined).
The implementation here is basically a big wad of C++. It was largely
copied from LLVM's own argument promotion pass, only doing the reverse.
In local testing this...
Closes#50154Closes#52636Closes#54583Closes#55059
[quite a lot]: https://github.com/rust-lang/rust/pull/47743
[discussion]: https://github.com/rust-lang/rust/issues/44367
[wasn't]: https://github.com/rust-lang/rust/issues/50154
Fixed: Multiple errors on single typo in match pattern
Here we have fixed the case where we were throwing two diagnostic messages `E0026` and `E0027` for same case.
Example
```
error[E0026]: variant `A::A` does not have a field named `fob`
--> src/test/ui/issue-52717.rs:20:12
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^ variant `A::A` does not have this field
error[E0027]: pattern does not mention field `foo`
--> src/test/ui/issue-52717.rs:20:5
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^^^^^^^^^^ missing field `foo`
error: aborting due to 2 previous errors
```
Here above we can see that both `E0026` and `E0027` are depicting
same thing.
So, to fix this issue, we are simply checking if for last element of `inexistent_fields` is there any value lies in `unmentioned_fields` using levenshtein algorithm, if it does then for that case we are simply deleting element from `unmentioned_fields`. More or less, now instead of showing separate message in `E0027` we are giving extra hint on `E0026`
r? @estebank
Allow explicit matches on ! without warning
It's now possible to explicitly match on `!` without an unreachable code warning. This seems desirable as promoting explicitness.
Fixes https://github.com/rust-lang/rust/issues/55116.
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
