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

E0277 explanation when using optional chaining can be improved #49694

Closed
learnopengles opened this issue Apr 5, 2018 · 7 comments
Closed

E0277 explanation when using optional chaining can be improved #49694

learnopengles opened this issue Apr 5, 2018 · 7 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@learnopengles
Copy link

learnopengles commented Apr 5, 2018

For this error:

 error[E0277]: the trait bound `std::option::Option<&Symbol>: std::ops::FnOnce<()>` is not satisfied
    --> JackCompiler.rs:302:19
     |
 302 |         let b = a.or_else(self.subroutine_symbols.get(name));
     |                   ^^^^^^^ the trait `std::ops::FnOnce<()>` is not implemented for `std::option::Option<&Symbol>`
 
 error: aborting due to previous error

The compiler can suggest adding a closure here. I'm honestly not sure what the issue is myself and I find optional and result chaining very difficult to use in Rust as compared to a language like Swift. However, changing it to a closure by adding "|| " fixed the error for me.

@XAMPPRocky XAMPPRocky added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 29, 2018
@estebank
Copy link
Contributor

estebank commented Jul 26, 2018

The traits Fn:

pub trait Fn<Args> : FnMut<Args> {

FnOnce:

pub trait FnOnce<Args> {

and FnMut:

pub trait FnMut<Args> : FnOnce<Args> {

need to have a #[rustc_on_unimplemented] attribute added, with a note suggesting the use of a closure and a short explanation of why the attempted code doesn't work.

@estebank estebank added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Jul 26, 2018
@lorian7392
Copy link

i'm a noob, but I would like to take this on if nobody else is working on that.

@lorian7392
Copy link

Hello @estebank , I am sorry that I have not worked before, because this time is working overtime.Now I built the compiler and tried adding the #[rustc_on_unimplemented] property, but I have some questions.
How does (crate_local, label='xxxx', note='xxx') in #[rustc_on_unimplemented] work? Is there any relevant information? Because I use the method in the example, but it doesn't work. Thank you very much for your help.

@estebank
Copy link
Contributor

crate_local filtering was added here. The machinery that parses rustc_on_unmplemented now lives here.

[crate_local is a flag added in error_reporting.rs only if the current evaluated scope is part of the local crate](

if let Some(true) = self_ty.ty_adt_def().map(|def| def.did.is_local()) {
flags.push(("crate_local".to_string(), None));
}
being compiled (in other words, your code). This means that if that flag is present, and crate_local rule was in rustc_on_unimplemented, then the following message/label/note will be shown. This is done so we can suggest code changes that are only valid if you have access to the source and we don't suggest, for example, changing code in Diesel, Serde or another dependency. These flags, IIRC, only work with on, as in #[rustc_on_unimlpemented(on(crate_local, note="the note"))].

Try first annotating with #[rustc_on_unimplemented(note="test")] to see if anything actually comes up, as I am now worried that there might be some special handling of closure traits.

Regardless, you can filter on any of the type arguments (including Self) as well, in the following way: #[rustc_on_unimlpemented(note="regular note", on(Args="()", note="the note if Fn<()>"))].

The documentation for the feature is at https://doc.rust-lang.org/unstable-book/language-features/on-unimplemented.html, but it is a bit out of date.

@estebank
Copy link
Contributor

Extended the documentation a bit in #53279.

@lorian7392
Copy link

lorian7392 commented Aug 12, 2018

hi @estebank . i try first annotating with #[rustc_on_unimplemented(note="test")] , but it not work. and
#[rustc_on_unimplemented = "test"] can work

@estebank
Copy link
Contributor

@LuGuoHuas I took a look to see what was needed and arrived at this #53296

kennytm added a commit to kennytm/rust that referenced this issue Aug 20, 2018
When closure with no arguments was expected, suggest wrapping

Fix rust-lang#49694.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants