Cannot `break` inside of an `async` block . . . WHY?

I have a loop inside a Tokio::spawn(async move{}), why am I not allowed to break? That seems nonsensical.

The error is ACTUALLY supposedly that the break keyword is outside of a loop, but it's not, so I am trying to figure out what's going on.

Why do you think that's the case?

That is the explicit error I am given when I compile

Can you share this error?

error[E0267]: break inside of an async block

Ah, once again I get bitten by bad messages from the error in VSCODE . . . if I look it up somehow my copy paste from outside the async move to inside the async move screwed something up and took the break outside the loop (I have no idea how). I have a bunch of digging to do.

Cannot break inside of an asyc block != A loop keyword ( break or continue ) was used inside a closure but outside of any loop.

One is helpful, the other is not!

The weird thing is that I literally copied and pasted the loop. I'm kinda confused.

I get it now. I'm still confused on how to fix it, but apparently the break was "moved" so now it's not part of the loop its part of an inner moved block . . .

I mean, when you tokio::spawn, you are creating an entirely independent task which will run completely separately from the current task. You can't control the task that spawned it.

The Rust compiler works hard to emit helpful error messages, but unfortunately these are often mangled by IDEs. You can always run cargo check from a terminal to see the full diagnostic (which you should also post here when you ask for help).

3 Likes

Actually Cargo check is not working for me. I'm getting dozens upon dozens of errors right now with Cargo Check, but if I use Cargo Run, I have three. The compiler is GREAT for errors and actually telling me what's going on, cargo and rust-analyzer I've found to be kinda buggy depending on what I'm doing. The problems are especially noticeable if VSCode is involved.

I REALLLY REALLLY wish there was a really solid alternative to VSCode!! VSCode seems to have lots of bugs on my platforms that literally crashes my PC on some updates. At times I can't suspend my PC, I literally have to shutdown between coding sessions . . .

You're probably redeclaring modules, so they get compiled several times and you get duplicate warnings and errors.

You may be right, but it also has something to do with macros and things I'm not directly using. A lot of it seems to have something to do with types declared in a crate called pnet, but none if it shows up unless I do cargo check.

I don't know offhand what could cause errors that are reported by cargo check but not by cargo build. The former just means "run all the compiler's normal analyses and checks without emitting any code". If you put your project in a public (cloneable) Git repo and link to it here we can probably diagnose what's going on.

I wish I could, but that's thousands of lines, a dozen files and not a few dependencies. I just don't think I could make that work reasonably. That and my code is written by a newb (me), so it's not really fit for public consumption, lol.

I mean, unless your project layout is really weird it should be as simple as

$ git init
$ git add src/**/*.rs Cargo.toml
$ git commit -m "Checkin for URLO"

And then pushing that to GitHub.

That and my code is written by a newb (me), so it's not really fit for public consumption, lol.

It's up to you of course, but looking at beginners' Rust code is pretty much what we all come to this forum to do :). You can always delete the repo later.

It's from Microsoft, so that seems about right to me. :wink:

I just use vim, but I wouldn't expect most people to be comfortable with that.

"Its from Microsoft . . . " I get the sentiment 100%!!
However, they're supposedly in a lovefest with Rust. You would think they could do better . . . then again: Windows . . . so I guess enough said.

I've seen clips of people using a configuration or two of NeoVim that looked pretty slick and usable for my flow, but while I can use Vim, getting a flow seems a bit like on of the black arts . . . best left to ancient masters. I also don't want to lose a couple weeks of my fairly limited personal time trying to configure something that might or might not work for me.

I'm all for taking a dig at MS software. But I have found VSCode to be one of the best products to ever come out of MS. At least the first one I find useful and have been actually happy to use.

I have used VSCode successfully quite a lot on Windows, a lot recently on Mac and often on Linux(Ubuntu).

Occasionally I have to do a check by hand to get a better look at the error messages.

Of course the above is a bit of an unhelpful "works for me" statement. We just have to find out why it does not work well for you.

3 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.