debuginfo: give unique names to closure and generator types
Closure types have been moved to the namespace where they
are defined, and both closure and generator type names now
include the disambiguator.
This fixes an exception when lldb prints nested closures.
Fixes#57822
I haven't included the `DW_AT_artificial` changes discussed in #57822 because they make the output worse IMO, but I can easily add these if still required. For example, for the new test case the output is now:
```
(lldb) p g
(issue_57822::main::closure-1) $1 = closure-1(closure(1))
```
but adding `DW_AT_artificial` changes this to:
```
(lldb) p g
(issue_57822::main::closure-1) $0 = closure-1 {
}
```
Note that nested generators didn't cause the exception. I haven't determined why, but I think it makes sense to add the disambiguator for them too. It feels like we still don't really understand why closures were causing an error though.
r? @michaelwoerister
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.
This introduces a WithFormatter abstraction that permits one-time
fmt::Display on an arbitrary closure, created via `display_fn`. This
allows us to prevent allocation while still using functions instead of
structs, which are a bit unwieldy to thread arguments through as they
can't easily call each other (and are generally a bit opaque).
The eventual goal here is likely to move us off of the formatting
infrastructure entirely in favor of something more structured, but this
is a good step to move us in that direction as it makes, for example,
passing a context describing current state to the formatting impl much
easier.
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
This allows us to pass it a `&mut DocContext` which will allow removal
of RefCells, etc. in the following commits. It's also somewhat a unique
Clean impl in that it previously ignored `self` (re-retriveing
hir::Crate), which it no longer needs to do.
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
