Removed a confusing FnOnce example
# Description
See #47091 for a discussion.
## Changes
- Removed an example that might suggest readers that square_x is (only) FnOnce.
closes#47091
VxWorks does not provide a way to set the task name except at creation time
Make set_name do thing as VxWorks does not provide a way to set the task name except at creation time.
r? @alexcrichton
cc @n-salim
Fully implement or-pattern parsing
Builds upon the initial parsing in https://github.com/rust-lang/rust/pull/61708 to fully implement or-pattern (`p | q`) parsing as specified in [the grammar section of RFC 2535](https://github.com/rust-lang/rfcs/blob/master/text/2535-or-patterns.md#grammar).
Noteworthy:
- We allow or-patterns in `[p | q, ...]`.
- We allow or-patterns in `let` statements and `for` expressions including with leading `|`.
- We improve recovery for `p || q` (+ tests for that in `multiple-pattern-typo.rs`).
- We improve recovery for `| p | q` in inner patterns (tests in `or-patterns-syntactic-fail.rs`).
- We rigorously test or-pattern parsing (in `or-patterns-syntactic-{pass,fail}.rs`).
- We harden the feature gating tests.
- We do **_not_** change `ast.rs`. That is, `ExprKind::Let.0` and `Arm.pats` still accept `Vec<P<Pat>>`.
I was starting work on that but it would be cleaner to do this in a separate PR so this one has a narrower scope.
cc @dlrobertson
cc the tracking issue https://github.com/rust-lang/rust/issues/54883.
r? @estebank
Point at method call on missing annotation error
Make it clearer where the type name that couldn't be inferred comes from.
Before:
```
error[E0282]: type annotations needed
--> src/test/ui/span/type-annotations-needed-expr.rs:2:13
|
2 | let _ = (vec![1,2,3]).into_iter().sum() as f64; //~ ERROR E0282
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for `S`
|
= note: type must be known at this point
```
after
```
error[E0282]: type annotations needed
--> src/test/ui/span/type-annotations-needed-expr.rs:2:39
|
2 | let _ = (vec![1,2,3]).into_iter().sum() as f64; //~ ERROR E0282
| ^^^ cannot infer type for `S`
|
= note: type must be known at this point
```
CC #63852.
Improve the documentation for std::hint::black_box.
The other day a colleague was reviewing some of my code which was using `black_box` to block constant propogation. There was a little confusion because the documentation kind of implies that `black_box` is only useful for dead code elimination, and only in benchmarking scenarios.
The docs currently say:
> A function that is opaque to the optimizer, to allow benchmarks to pretend to use outputs to assist in avoiding dead-code elimination.
Here is our discussion, in which I show (using godbolt) that a black box can also block constant propagation:
https://github.com/softdevteam/yk/pull/21#discussion_r302985038
This change makes the docstring for `black_box` a little more general, and while we are here, I've added an example (the same one from our discussion).
OK to go in?
Permit unwinding through FFI by default
This repeats #62505 for master (Rust 1.38+), as #58794 is not yet resolved. This is a stopgap until a stable alternative is available, like [RFC 2699](https://github.com/rust-lang/rfcs/pull/2699), as long as progress is being made to that end.
r? @joshtriplett
typeck: refactor patterns => `pat.rs` + make the `def_bm` algo more declarative
Spurred by the relative difficulty I had in working up an explanation of how default match bindings work in https://github.com/rust-lang/rust/pull/63118#issuecomment-524161584, this PR refactors the type checking of patterns into `pat.rs`.
The PR is probably best read commit-by-commit and includes various changes beyond the following, which are the most important highlights:
- The algorithm for determining `def_bm` is encoded in a more declarative fashion now with important sub-steps divided into functions that make sense as logical units (and as described in the reference). This is done starting with *"extract `is_no_ref_pat`."* to *"extract `calc_default_binding_mode`"*.
- Dedicated functions like `check_pat_{lit,range,ident,tuple,box,ref,slice}` are then introduced for the various kinds of patterns to make things overall more readable.
- `fn check_pat_top(...)` becomes the sole entry point to type checking patterns.
This will take care of initializing the default binding mode (hence: `def_bm`) to `BindByValue` and is called by all contexts that have a pattern that needs to be type checked (functions, `match`, `if let`, `let`, ...). The overall result is that the notion of `def_bm` is internal to checking patterns.
- Various diagnostics are extracted to dedicated functions to disturb the flow of type checking logic less.
r? @oli-obk
Rollup of 6 pull requests
Successful merges:
- #62744 (Refactor `TinyList::contains` and `len` to iterate instead of recurse)
- #63813 (Do not suggest `.try_into()` on `i32::from(x)`)
- #63833 (Suggest calling closure with resolved return type when appropriate)
- #63839 (Ensure miri can do bit ops on pointer values)
- #63854 (Modifies how Arg, Arm, Field, FieldPattern and Variant are visited)
- #63859 (Don't unwrap the result of `span_to_snippet`)
Failed merges:
r? @ghost
Suggest calling closure with resolved return type when appropriate
Follow up to #63337. CC #63100.
```
error[E0308]: mismatched types
--> $DIR/fn-or-tuple-struct-without-args.rs:46:20
|
LL | let closure = || 42;
| -- closure defined here
LL | let _: usize = closure;
| ^^^^^^^
| |
| expected usize, found closure
| help: use parentheses to call this closure: `closure()`
|
= note: expected type `usize`
found type `[closure@$DIR/fn-or-tuple-struct-without-args.rs:45:19: 45:24]`
```
