Rollup of 4 pull requests
Successful merges:
- #62600 (libtest: add --show-output flag to print stdout of successful tests)
- #63698 (Fixed floating point issue with asinh function)
- #63761 (Propagate spans and attributes from proc macro definitions)
- #63917 (Error when generator trait is not found)
Failed merges:
r? @ghost
Propagate spans and attributes from proc macro definitions
Thanks to https://github.com/rust-lang/rust/pull/63269 we now have spans and attributes from proc macro definitions available in metadata.
However, that PR didn't actually put them into use! This PR finishes that work.
Attributes `rustc_macro_transparency`, `allow_internal_unstable`, `allow_internal_unsafe`, `local_inner_macros`, `rustc_builtin_macro`, `stable`, `unstable`, `rustc_deprecated`, `deprecated` now have effect when applied to proc macro definition functions.
From those attributes only `deprecated` is both stable and supposed to be used in new code.
(`#![staged_api]` still cannot be used in proc macro crates for unrelated reasons though.)
`Span::def_site` from the proc macro API now returns the correct location of the proc macro definition.
Also, I made a mistake in https://github.com/rust-lang/rust/pull/63269#discussion_r312702919, loaded proc macros didn't actually use the resolver cache.
This PR fixes the caching issue, now proc macros go through the `Resolver::macro_map` cache as well.
(Also, the first commit turns `proc_macro::quote` into a regular built-in macro to reduce the number of places where `SyntaxExtension`s need to be manually created.)
Fixed floating point issue with asinh function
This should fixes#63271 , in which `asinh(-0.0)` returns `0.0` instead of `-0.0`.
according to @nagisa
>
>
> IEEE-754 (2008), section 9.2.1:
>
> > For the functions expm1, exp2m1, exp10m1, logp1, log2p1, log10p1, sin, tan, sinPi, atanPi, asin, atan, sinh, tanh, asinh, and atanh, f(+0) is +0 and f(−0) is −0 with no exception.
>
> and
>
> > sinh(±∞) and asinh(±∞) are ±∞ with no exception.
After ensuring that the function `asinh` is the only function affected (functions like `sin`, `sinh` are all based on `cmath` library or `llvm` intrinsics), and that `atanh` always gives the correct result. The only function to modify is `asinh`.
libtest: add --show-output flag to print stdout of successful tests
This pull request adds a new flag `--show-output` for tests to show the output of successful tests. For most formatters this was already supported just not exposed via the CLI (apparently only used by `librustdoc`). I've also added support for this option in the JSON formatter.
This kind of fixes https://github.com/rust-lang/rust/issues/54669 which wants `--format json` to work with `--nocapture`, which is... well, impossible. What this issue really calls for is `--show-output` as implemented here.
Rollup of 6 pull requests
Successful merges:
- #63317 (Do not complain about unused code when used in `impl` `Self` type)
- #63693 (Fully implement or-pattern parsing)
- #63836 (VxWorks does not provide a way to set the task name except at creation time)
- #63845 (Removed a confusing FnOnce example)
- #63855 (Refactor feature gates)
- #63921 (add link to FileCheck docs)
Failed merges:
r? @ghost
Refactor feature gates
After #63824, this goes a few steps further by
- parsing doc comments in the macros to extract descriptions for feature gates, and
- introducing a common `Feature` type to replace the tuples used previously to improve readability.
The descriptions are not yet used, but I felt like this PR is a useful enough refactoring on its own.
r? @Centril
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
This replaces the ad-hoc tuples used in the different feature gate files
and unifies their content into a common type, leading to more readable
matches and other good stuff that comes from having named fields. It
also contains the description of each feature as extracted from the doc
comment.
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]`
```
