This prevents mistakes where the feature is in the list of incomplete
features but not actually a feature by making the incompleteness a part
of the declaration.
This creates a CSV with name "closure_profile_XXXXX.csv", where the
variable part is the process id of the compiler.
To profile a cargo project you can run one of the following depending on
if you're compiling a library or a binary:
```
cargo +stage1 rustc --lib -- -Zprofile-closures
cargo +stage1 rustc --bin -- -Zprofile-closures
```
Rollup of 6 pull requests
Successful merges:
- #86206 (Fix type checking of return expressions outside of function bodies)
- #86358 (fix pretty print for `loop`)
- #86568 (Don't dist miri or rust-analyzer on stable or beta.)
- #86683 (⬆️ rust-analyzer)
- #86687 (Allow anyone to set `perf-regression` label)
- #86688 (Add a regression test for issue-65384)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't dist miri or rust-analyzer on stable or beta.
This prevents miri and rust-analyzer from being built for "dist" or "install" on the stable/beta channels. It is a nightly-only tool and should not be included.
Closes#86286
Fix type checking of return expressions outside of function bodies
This pull request fixes#86188. The problem is that the current code for type-checking `return` expressions stops if the `return` occurs outside of a function body, while the correct behavior is to continue type-checking the return value expression (otherwise an ICE happens later on because variables declared in the return value expression don't have a type).
Also, I have noticed that it is sometimes not obvious why a `return` is outside of a function body; for instance, in the example from #86188 (which currently causes an ICE):
```rust
fn main() {
[(); return || {
let tx;
}]
}
```
I have changed the error message to also explain why the `return` is considered outside of the function body:
```
error[E0572]: return statement outside of function body
--> ice0.rs:2:10
|
1 | / fn main() {
2 | | [(); return || {
| |__________^
3 | || let tx;
4 | || }]
| ||_____^ the return is part of this body...
5 | | }
| |_- ...not the enclosing function body
```
Add suspicious group
changelog: Introduce `clippy::suspicious` 🤔 group and move several lints into the group
Closes#6366. CC #6626.
A number of lints are moved from each of `correctness`, `style` and `complexity` groups. Notably I didn't move `suspicious_splitn` since I think that is a `correctness` lint despite the name.
Lints moved to `clippy::suspicious`:
* `blanket_clippy_restriction_lints` (was `clippy::style`)
* `empty_loop` (was `clippy::style`)
* `eval_order_dependence` (was `clippy::complexity`)
* `float_equality_without_abs` (was `clippy::correctness`)
* `for_loops_over_fallibles` (was `clippy::correctness`)
* `misrefactored_assign_op` (was `clippy::complexity`)
* `mut_range_bound` (was `clippy::complexity`)
* `mutable_key_type` (was `clippy::correctness`)
* `suspicious_arithmetic_impl` (was `clippy::correctness`)
* `suspicious_assignment_formatting` (was `clippy::style`)
* `suspicious_else_formatting` (was `clippy::style`)
* `suspicious_map` (was `clippy::complexity`)
* `suspicious_op_assign_impl` (was `clippy::correctness`)
* `suspicious_unary_op_formatting` (was `clippy::style`)
Fix typo in libs tracking issue template
Currently, the libs tracking issue template expands FCP as "final commenting period". Everywhere else, including in [the official explanation](https://rust-lang.github.io/rfcs/), it's expanded as "final comment period". That version also sounds a bit better. Accordingly, this PR changes the tracking issue template to use that version.
`@rustbot` label A-meta T-libs-api
r? `@m-ou-se`
Reserve prefixed identifiers and literals (RFC 3101)
This PR denies any identifiers immediately followed by one of three tokens `"`, `'` or `#`, which is stricter than the requirements of RFC 3101 but may be necessary according to the discussion at [Zulip].
[Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/reserved.20prefixes/near/238470099
The tracking issue #84599 says we'll add a feature gate named `reserved_prefixes`, but I don't think I can do this because it is impossible for the lexer to know whether a feature is enabled or not. I guess determining the behavior by the edition information should be enough.
Fixes#84599
2229: Capture box completely in move closures
Even if the content from box is used in a sharef-ref context,
we capture the box entirerly.
This is motivated by:
1) We only capture data that is on the stack.
2) Capturing data from within the box might end up moving more data than
the user anticipated.
Closes https://github.com/rust-lang/project-rfc-2229/issues/50
r? `@nikomatsakis`
This causes Windows Defender's firewall to pop up during tests to ask if
I want to allow the test program to access the public Internet, since it
was listening on `0.0.0.0`. The test server doesn't actually need to be
publically reachable, so this makes it so it is only reachable locally,
which makes Windows Defender happy.
Revert revert of constness in #86003
Re-constify `mem::swap`, `mem::replace`, `ptr::write` which were marked as not `const` in #86003
Once the checks pass, this should solve #86236
