remove empty wraps, don't return Results from from infallible functions
This makes code easier to understand because it is more obvious when a function actually can't fail (return Err or None)
Make functions that only ever return Some(x), return x directly
Remove return type from functions that return Option<(), Err> but would only ever return Ok(()).
Found with `clippy::unnecessary_wraps`
remove unused return type of dropck::check_drop_obligations()
don't wrap return type in Option in get_macro_by_def_id() since we would always return Some(..)
remove redundant return type of back::write::optimize()
don't Option-wrap return type of compute_type_parameters() since we always return Some(..)
don't return empty Result in assemble_generator_candidates()
don't return empty Result in assemble_closure_candidates()
don't return empty result in assemble_fn_pointer_candidates()
don't return empty result in assemble_candidates_from_impls()
don't return empty result in assemble_candidates_from_auto_impls()
don't return emtpy result in assemble_candidates_for_trait_alias()
don't return empty result in assemble_builtin_bound_candidates()
don't return empty results in assemble_extension_candidates_for_traits_in_scope() and assemble_extension_candidates_for_trait()
remove redundant wrapping of return type of StripItem::strip() since it always returns Some(..)
remove unused return type of assemble_extension_candidates_for_all_traits()
Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121
Previously, using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example:
```rust
fn f() -> i32 { 0 }
fn fn_ptr() -> _ { f }
fn closure() -> _ { || 0 }
```
would result in this diagnostic:
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32 {f}`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `[closure@<anon>:3:21: 3:25]`
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen, it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally, closures cause a papercut as unique closure types (notated in this case as `[closure@<anon>:3:21: 3:25]`) are not valid syntax either.
Instead, this PR implements this version of the diagnostic (this example is for the same code featured above):
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^ not allowed in type signatures
|
= help: consider using an `Fn`, `FnMut`, or `FnOnce` trait bound
= note: for more information on `Fn` traits and closure types, see https://doc.rust-lang.org/book/ch13-01-closures.html
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen in this diagnostic, the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures, it's suggested to use an `Fn`, `FnMut`, or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment, therefore someone in the future may want to implement that. Also, it's possible to use either `impl Trait` syntax, generics, or generics with a `where` clause, and some users may not want to use `impl Trait` syntax for their own reasons.
This PR fixes#80179.
`replace_prefix` is currently implemented as a method but has no real relation
to the struct it is implemented on. Turn it into a closure and move it into the
only method from which it is called.
Reserve necessary space for params in generics_of
Always reserve space for the exact number of generic parameters we need in generics_of. As far as I can see, the default is 0/4 elements based on has_self, and the vector grows on after that.
Turn quadratic time on number of impl blocks into linear time
Previously, if you had a lot of inherent impl blocks on a type like:
```Rust
struct Foo;
impl Foo { fn foo_1() {} }
// ...
impl Foo { fn foo_100_000() {} }
```
The compiler would be very slow at processing it, because
an internal algorithm would run in O(n^2), where n is the number
of impl blocks. Now, we add a new algorithm that allocates but
is faster asymptotically.
Comparing rustc nightly with a local build of rustc as of this PR (results in seconds):
| N | real time before | real time after |
| - | - | - |
| 4_000 | 0.57 | 0.46 |
| 8_000 | 1.31 | 0.84 |
| 16_000 | 3.56 | 1.69 |
| 32_000 | 10.60 | 3.73 |
I've tuned up the numbers to make the effect larger than the startup noise of rustc, but the asymptotic difference should hold for smaller n as well.
Note: current state of the PR omits error messages if there are other errors present already. For now, I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!
Make BoundRegion have a kind of BoungRegionKind
Split from #76814
Also includes making `replace_escaping_bound_vars` only return `T`
Going to r? `@lcnr`
Feel free to reassign
Move binder for dyn to each list item
This essentially changes `ty::Binder<&'tcx List<ExistentialTraitRef>>` to `&'tcx List<ty::Binder<ExistentialTraitRef>>`.
This is a first step in moving the `dyn Trait` representation closer to Chalk, which we've talked about in `@rust-lang/wg-traits.`
r? `@nikomatsakis`
Implement if-let match guards
Implements rust-lang/rfcs#2294 (tracking issue: #51114).
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` ❤️ for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
Take into account negative impls in "trait item not found" suggestions
This removes the suggestion to implement a trait for a type when that type already has a negative implementation for the trait, and replaces it with a note to point out that the trait is explicitely unimplemented, as suggested by `@scottmcm.`
Helps with #79683.
r? `@scottmcm` do you want to review this?
Resolve enum field visibility correctly
Fixes#79593. 🎉
Previously, this code treated enum fields' visibility as if they were
struct fields. However, that's not correct because the visibility of a
struct field with `ast::VisibilityKind::Inherited` is private to the
module it's defined in, whereas the visibility of an *enum* field with
`ast::VisibilityKind::Inherited` is the visibility of the enum it
belongs to.
fix more clippy::complexity findings
fix clippy::unnecessary_filter_map
use if let Some(x) = .. instead of ...map(|x|) to conditionally run fns that return () (clippy::option_map_unit_fn)
fix clippy::{needless_bool, manual_unwrap_or}
don't clone types that are copy (clippy::clone_on_copy)
don't convert types into identical types with .into() (clippy::useless_conversion)
use strip_prefix over slicing (clippy::manual_strip)
r? ``@Dylan-DPC``
Previously, this code treated enum fields' visibility as if they were
struct fields. However, that's not correct because the visibility of a
struct field with `ast::VisibilityKind::Inherited` is private to the
module it's defined in, whereas the visibility of an *enum* field with
`ast::VisibilityKind::Inherited` is the visibility of the enum it
belongs to.
Capture precise paths in THIR and MIR
This PR allows THIR and MIR to use the result of the new capture analysis to actually capture precise paths
To achieve we:
- Writeback min capture results to TypeckResults
- Move handling upvars to PlaceBuilder in mir_build
- Lower precise paths in THIR build by reading min_captures
- Search for ancestors in min_capture when trying to build a MIR place which starts off of an upvar
Closes: https://github.com/rust-lang/project-rfc-2229/issues/10
Partly implements: rust-lang/project-rfc-2229#18
Work that remains (not in this PR):
- [ ] [Known bugs when feature gate is enabled](https://github.com/rust-lang/project-rfc-2229/projects/1?card_filter_query=label%3Abug)
- [ ] Use min_capure_map for
- [ ] Liveness analysis
- [ ] rustc_mir/interpret/validity.rs
- [ ] regionck
- [ ] rust-lang/project-rfc-2229#8
- [ ] remove closure_captures and upvar_capture_map
r? `@ghost`
Strip prefix instead of replacing it with empty string
r? `@lcnr,` since you reviewed my other PR in the area.
`@rustbot` modify labels +C-cleanup +T-compiler
Replace simple `if let` constructs with Option::map
Replaces a few constructs of the form
```
if let Some(x) = var {
Some(...)
} else {
None
}
```
with calls to `Option::map`.
`@rustbot` modify labels +C-cleanup +T-compiler
Validate naked functions definitions
Validate that naked functions are defined in terms of a single inline assembly
block that uses only `const` and `sym` operands and has `noreturn` option.
Implemented as future incompatibility lint with intention to migrate it into
hard error. When it becomes a hard error it will ensure that naked functions are
either unsafe or contain an unsafe block around the inline assembly. It will
guarantee that naked functions do not reference functions parameters (obsoleting
part of existing checks from #79411). It will limit the definitions of naked
functions to what can be reliably supported. It will also reject naked functions
implemented using legacy LLVM style assembly since it cannot satisfy those
conditions.
https://github.com/rust-lang/rfcs/pull/2774https://github.com/rust-lang/rfcs/pull/2972
