Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ignore] testing #80428

Closed
wants to merge 35 commits into from
Closed

[ignore] testing #80428

wants to merge 35 commits into from

Conversation

ThePuzzlemaker
Copy link
Contributor

@ThePuzzlemaker ThePuzzlemaker commented Dec 28, 2020

This was just a failed test, please ignore it. Sorry if I wasted anyone's time :(

XAMPPRocky and others added 30 commits December 7, 2020 23:45
Co-authored-by: Jonas Schievink <[email protected]>
Co-authored-by: Vadim Petrochenkov <[email protected]>
Co-authored-by: Jonas Schievink <[email protected]>
…ds rather than the unique closure type in E0121

This is a squash of the titular commit along with these minor commits:
- Improve note
- Improve note pt2
This also adds back a comment that was mistakenly removed in
ac9dfc3.
Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121

Previously, using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example:
```rust
fn f() -> i32 { 0 }
fn fn_ptr() -> _ { f }
fn closure() -> _ { || 0 }
```
would result in this diagnostic:
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> <anon>:2:16
  |
2 | fn fn_ptr() -> _ { f }
  |                ^
  |                |
  |                not allowed in type signatures
  |                help: replace with the correct return type: `fn() -> i32 {f}`

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> <anon>:3:17
  |
3 | fn closure() -> _ { || 0 }
  |                 ^
  |                 |
  |                 not allowed in type signatures
  |                 help: replace with the correct return type: `[closure@<anon>:3:21: 3:25]`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0121`.
```
As can be seen, it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally, closures cause a papercut as unique closure types (notated in this case as `[closure@<anon>:3:21: 3:25]`) are not valid syntax either.

Instead, this PR implements this version of the diagnostic (this example is for the same code featured above):
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> <anon>:2:16
  |
2 | fn fn_ptr() -> _ { f }
  |                ^
  |                |
  |                not allowed in type signatures
  |                help: replace with the correct return type: `fn() -> i32`

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> <anon>:3:17
  |
3 | fn closure() -> _ { || 0 }
  |                 ^ not allowed in type signatures
  |
  = help: consider using an `Fn`, `FnMut`, or `FnOnce` trait bound
  = note: for more information on `Fn` traits and closure types, see https://doc.rust-lang.org/book/ch13-01-closures.html

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0121`.
```
As can be seen in this diagnostic, the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures, it's suggested to use an `Fn`, `FnMut`, or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment, therefore someone in the future may want to implement that. Also, it's possible to use either `impl Trait` syntax, generics, or generics with a `where` clause, and some users may not want to use `impl Trait` syntax for their own reasons.

This PR fixes #80179.
Add more comments to trait queries

This also adds back a comment that was mistakenly removed in
ac9dfc3.
use matches!() macro in more places
BTreeMap: test split_off (and append) more thoroughly

Using DeterministicRng as a poor man's property based testing rig.
r? `@Mark-Simulacrum`
clarify wrapping ptr arithmetic docs

Fixes #80306

`@steffahn` please let me know if this helps avoid the misunderstanding. :)
…acrum

BTreeMap: rename the area access methods

r? `@Mark-Simulacrum`
Add links to the source for the rustc and rustdoc books.

This adds a little icon in the upper-right corner of the books so that readers can find the source if they want to make changes or file issues. This is already included in several of the other books.
Remove FIXME in rustc_privacy

#71104 has been fixed.

r? `@marmeladema` if you have time, otherwise `@petrochenkov`
fix: small typo error in chalk/mod.rs
rustdoc book: fix example

`lib.rs` file is created only if `--lib` flag is specified
Add regression test for #80375

This will also make sure that #80375 is handled if #79135 has to be reverted (which won't happen 🤞).

Closes #80375.
r? `@lcnr`
@rustbot
Copy link
Collaborator

rustbot commented Dec 28, 2020

Error: Label rollup can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

@ThePuzzlemaker ThePuzzlemaker changed the title Rollup of 13 pull requests [ignore] testing Dec 28, 2020
@rustbot
Copy link
Collaborator

rustbot commented Dec 28, 2020

Error: Label rollup can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

@ThePuzzlemaker
Copy link
Contributor Author

Just testing something, please ignore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.