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

Uses of "do catch" suggest non-working "try" instead #53672

Closed
RalfJung opened this issue Aug 24, 2018 · 10 comments
Closed

Uses of "do catch" suggest non-working "try" instead #53672

RalfJung opened this issue Aug 24, 2018 · 10 comments
Assignees
Labels
C-bug Category: This is a bug.

Comments

@RalfJung
Copy link
Member

RalfJung commented Aug 24, 2018

I have code like this

    let action : Result<Action, Error> = do catch {
        let signed_action = base64::decode(form.signed_action.as_str())?;
        let signed_action: SignedAction = deserialize_from_slice(signed_action.as_slice())?;
        signed_action.verify(&config.secrets.action_signing_key)?
    };

after updating nightly, this does not compile any more. It says

error: found removed `do catch` syntax
   --> src/routes.rs:164:42
    |
164 |     let action : Result<Action, Error> = do catch {
    |                                          ^^
    |
    = help: Following RFC #2388, the new non-placeholder syntax is `try`

So I tried

    let action : Result<Action, Error> = try {
        let signed_action = base64::decode(form.signed_action.as_str())?;
        let signed_action: SignedAction = deserialize_from_slice(signed_action.as_slice())?;
        signed_action.verify(&config.secrets.action_signing_key)?
    };

but that does not compile either

error: expected identifier, found keyword `let`
   --> src/routes.rs:164:9
    |
163 |     let action : Result<Action, Error> = try {
    |                                          --- while parsing this struct
164 |         let signed_action = base64::decode(form.signed_action.as_str())?;
    |         ^^^ expected identifier, found keyword

I have also tried try catch, to no avail.

At the very least, the error message about "do catch" needs to be improved, as its advise is clearly incorrect. But also, I wonder what I should do now :D I guess I'll use an immediately-applied closure again...

@kennytm kennytm added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Aug 24, 2018
@Centril Centril added C-bug Category: This is a bug. and removed A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Aug 25, 2018
@Centril
Copy link
Contributor

Centril commented Aug 25, 2018

cc @scottmcm

@scottmcm
Copy link
Member

scottmcm commented Aug 25, 2018

@RalfJung Oh, right, the error message should mention that you need to be in the 2018 edition.

(I could also make do catch or do try work temporarily in 2015, I suppose...)

@scottmcm scottmcm self-assigned this Aug 25, 2018
@durka
Copy link
Contributor

durka commented Aug 25, 2018

So is do catch going to be removed from 2015 with no replacement? That's not very nice.

@Centril
Copy link
Contributor

Centril commented Aug 27, 2018

@durka It was never the plan to stabilize do catch; it was always a temporary syntax.

@scottmcm
Copy link
Member

@durka Do you have a case where you have nightly 2015 code that cannot migrate to nightly 2018?

@jonhoo
Copy link
Contributor

jonhoo commented Sep 6, 2018

I'm confused. Even with

#![feature(rust_2018_preview)]

the syntax

let foo: Result<_, _> = try {
    // ...
};

still does not work?

@jonhoo
Copy link
Contributor

jonhoo commented Sep 6, 2018

Ahh, it looks like you also need edition = 2018 in your Cargo.toml as outlined in the transition guide.

@varkor
Copy link
Member

varkor commented Sep 13, 2018

This was very confusing to run into (for some reason this error occurs on Travis, but not locally for me). It'd make much more sense to me to allow do catch before the 2018 edition.

Centril added a commit to Centril/rust that referenced this issue Feb 22, 2019
Add a note about 2018e if someone uses `try {` in 2015e

Inspired by rust-lang#58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.

What's the philosophy about gating for this?  The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_.  Let me know if I should do differently.

Resolves rust-lang#53672
Centril added a commit to Centril/rust that referenced this issue Feb 22, 2019
Add a note about 2018e if someone uses `try {` in 2015e

Inspired by rust-lang#58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.

What's the philosophy about gating for this?  The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_.  Let me know if I should do differently.

Resolves rust-lang#53672
@scottmcm
Copy link
Member

I've closed this now that there's an additional message about the edition on try. That's not amazing, but this is also a nightly-only thing.

Have you perchance been able to use try{} in nightly 2018 edition now, @RalfJung?

@RalfJung
Copy link
Member Author

Have you perchance been able to use try{} in nightly 2018 edition now, @RalfJung?

Yes, they seem to work as intended. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

7 participants