compiler help from hellpic.twitter.com/2ueZ5ULSqG
Show this thread
-
-
-
Replying to @ekuber @isislovecruft
What happens is that then a closing brace is missing, the compiler does its best to try to recover and auto inject a closing brace in a place it has a high degree of certainty one should go. But this doesn't always work well.
1 reply 0 retweets 5 likes -
Replying to @ekuber @isislovecruft
Because it tries so hard to recover, the parser can get itself in a place where it thinks it's parsing trait items (which are only fn, type and const), but it encounters tons of other things that were never meant to be in the trait but rather the enclosing mod.
1 reply 0 retweets 0 likes -
Replying to @ekuber @isislovecruft
For what is worth, this shouldn't happen in the latest nightly anymore. We made the recovery much dumber, where the parser will just swallow the remainder of the block without an attempt to parse it.https://github.com/rust-lang/rust/pull/65838 …
1 reply 0 retweets 1 like -
Replying to @ekuber @isislovecruft
If it is an unclosed brace, it will just swallow everything after the first parse error. This has the side effect of leading to complaints about some traits not existing, but at least it will no longer complain about parse errors that make no sense.
1 reply 0 retweets 0 likes -
Replying to @ekuber
it was actually because i tried to define an enum inside another enum, so that i could do `InternalError::AggregateSigning::CommitmentOpeningError` rather than `InternalError(AggregateSigning::CommitmentOpeningError)`
2 replies 0 retweets 2 likes -
-
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.