Detect missing `;` on methods with return type `()`
- Point out the origin of a type requirement when it is the return type
of a method
- Point out possibly missing semicolon when the return type is `()` and
the implicit return makes sense as a statement
- Suggest changing the return type of methods with default return type
- Don't suggest changing the return type on `fn main()`
- Don't suggest changing the return type on impl fn
- Suggest removal of semicolon (instead of being help)
Reuse the mem::swap optimizations to speed up slice::rotate
This is most helpful for compound types where LLVM didn't vectorize the loop. Highlight: bench slice::rotate_medium_by727_strings gets 38% faster.
Exposes the swapping logic from PR https://github.com/rust-lang/rust/pull/40454 as `pub unsafe fn ptr::swap_nonoverlapping` under library feature `swap_nonoverlapping` https://github.com/rust-lang/rust/issues/42818.
(The new method seemed plausible, and was the simplest way to share the logic. I'm not attached to it, though, so let me know if a different way would be better.)
Turn `elaborate_drops` and `rustc_peek` implementations into MIR
passes that also live in `rustc_mir` crate.
Rewire things so `rustc_driver` uses the `ElaborateDrops` from
`rustc_mir` crate.
re-add the call to `super_statement` in EraseRegions
The move gathering code is sensitive to type-equality - that is rather
un-robust and I plan to fix it eventually, but that's a more invasive
change. And we want to fix the visitor anyway.
Fixes#42903.
r? @eddyb
The move gathering code is sensitive to type-equality - that is rather
un-robust and I plan to fix it eventually, but that's a more invasive
change. And we want to fix the visitor anyway.
Fixes#42903.
Fix NaN handling in is_sign_negative/positive
This would be my proposed fix for the #42425 provided we decide it is indeed a problem.
Note this would technically be a breaking change to a stable API. We might want to consider deprecating these methods and adding new ones.
Don't drag function signatures along function item types.
This PR separates the signature of a function from the "function item type" (`TyFnDef`), leaving only the `DefId` and parameter `Substs`, making them even more like (captureless) closure types.
The motivation for this change is reducing typesystem complexity, and its consequences:
* operating on the signature instead of just the parameters was less efficient
* specifically, signatures can easily add several levels of depth on top of the parameter types
* and the signatured were always substituted and normalized, so typically even more complex
* it was *the only* type that was *both* nominal (identity) and structural (signature)
* harder to model in Chalk than either a purely nominal or structural type
* subtyping worked on the signature but parameters were always invariant
* call type-checking was transforming signatures but keeping the nominal half intact
* the signature could therefore get out of sync during type inference in several ways
That last point comes with a `[breaking-change]`, because functions with `'static` in their return types will now *not* be as usable as if they were using lifetime parameters instead:
```rust
// Will cause lifetime mismatch in main after this PR.
fn bar() -> &'static str { "bar" }
// Will continue to work fine, as every use can choose its own lifetime.
fn bar<'a>() -> &'a str { "bar" }
fn main() {
let s = String::from("foo");
Some(&s[..]).unwrap_or_else(bar);
}
```
r? @nikomatsakis
Try to make clear that this isn't an API guarantee for now, as we likely
want to refine these errors in the future, e.g. `ENOSPC` "No space left
on device".
CC #40322
Reword OsStr docs to clarify that utf8 may contain nulls
The use of the word "but" in the OsStr docs implies (at least to me) that valid UTF-8 does not contain null bytes.
Using "which" instead makes it clear that valid UTF-8 may contain null bytes.
only set "overruled by outer forbid" once for lint groups, by group name
Previously, conflicting forbid/allow attributes for a lint group would
result in a separate "allow(L) overruled by outer forbid(L)" error for
every lint L in the group. This was needlessly and annoyingly verbose;
we prefer to just have one error pointing out the conflicting
attributes.
(Also, while we're touching context.rs, clean up some unused arguments.)
Resolves#42873.
change binding name of for loop lowering to appease clippy
With the latest change to for loop lowering (#42634), a `_next` binding was introduced.
Unfortunately, this [disturbs](https://github.com/Manishearth/rust-clippy/issues/1846) clippy's `used_underscore_binding` lint. This commit just renames the binding to `__next` so clippy will be happy. It should have no other effect.
Expand Derivable docblock section for `Ord` and `PartialOrd` to cover
`enum` types, in addition to the existing language explaining it for
`struct` types.
