rust/tests/ui/loops/loop-break-value-no-repeat.stderr

error[E0571]: `break` with value from a `for` loop
  --> $DIR/loop-break-value-no-repeat.rs:12:9
   |
LL |     for _ in &[1,2,3] {
   |     ----------------- you can't `break` with a value in a `for` loop
LL |         break 22
   |         ^^^^^^^^ can only break with a value inside `loop` or breakable block
   |
help: use `break` on its own without a value inside this `for` loop
   |
LL |         break
   |         ~~~~~

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0571`.
rework how we handle the type of loops First, we keep a `CoerceMany` now to find the LUB of all the break expressions. Second, this `CoerceMany` is actually an `Option<CoerceMany>`, and we store `None` for loops where "break with an expression" is disallowed. This avoids silly duplicate errors about a type mismatch, since the loops pass already reports an error that the break cannot have an expression. Finally, since we now detect an invalid break target during HIR lowering, refactor `find_loop` to be infallible. Adjust tests as needed: - some spans from breaks are slightly different - break up a single loop into multiple since `CoerceMany` silences redundant and derived errors - add a ui test that we only give on error for loop-break-value 2017-03-17 15:49:53 +00:00			error[E0571]: `break` with value from a `for` loop
Remove licenses 2018-12-25 15:56:47 +00:00			`--> $DIR/loop-break-value-no-repeat.rs:12:9`
rework how we handle the type of loops First, we keep a `CoerceMany` now to find the LUB of all the break expressions. Second, this `CoerceMany` is actually an `Option<CoerceMany>`, and we store `None` for loops where "break with an expression" is disallowed. This avoids silly duplicate errors about a type mismatch, since the loops pass already reports an error that the break cannot have an expression. Finally, since we now detect an invalid break target during HIR lowering, refactor `find_loop` to be infallible. Adjust tests as needed: - some spans from breaks are slightly different - break up a single loop into multiple since `CoerceMany` silences redundant and derived errors - add a ui test that we only give on error for loop-break-value 2017-03-17 15:49:53 +00:00			`\|`
Tweak error for invalid `break expr` Point at loop head on invalid `break expr`. Suggest removing `expr` or using label if available. 2021-01-21 01:25:27 +00:00			`LL \| for _ in &[1,2,3] {`
			\| ----------------- you can't `break` with a value in a `for` loop
Update tests 2019-03-09 12:03:44 +00:00			`LL \| break 22`
Make the compiler support the label-break-value feature No error checking or feature gating yet 2018-04-25 17:28:04 +00:00			\| ^^^^^^^^ can only break with a value inside `loop` or breakable block
Increase spacing for suggestions in diagnostics Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages. 2019-10-24 05:20:58 +00:00			`\|`
Tweak error for invalid `break expr` Point at loop head on invalid `break expr`. Suggest removing `expr` or using label if available. 2021-01-21 01:25:27 +00:00			help: use `break` on its own without a value inside this `for` loop
Suggest removing value from `break` when invalid 2018-01-28 19:14:09 +00:00			`\|`
Update tests 2019-03-09 12:03:44 +00:00			`LL \| break`
Modify structured suggestion output * On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span 2021-06-22 02:07:19 +00:00			`\| ~~~~~`
rework how we handle the type of loops First, we keep a `CoerceMany` now to find the LUB of all the break expressions. Second, this `CoerceMany` is actually an `Option<CoerceMany>`, and we store `None` for loops where "break with an expression" is disallowed. This avoids silly duplicate errors about a type mismatch, since the loops pass already reports an error that the break cannot have an expression. Finally, since we now detect an invalid break target during HIR lowering, refactor `find_loop` to be infallible. Adjust tests as needed: - some spans from breaks are slightly different - break up a single loop into multiple since `CoerceMany` silences redundant and derived errors - add a ui test that we only give on error for loop-break-value 2017-03-17 15:49:53 +00:00
Show number in error message even for one error Co-authored-by: Adrian <adrian.iosdev@gmail.com> 2023-11-21 15:44:16 +00:00			`error: aborting due to 1 previous error`
rework how we handle the type of loops First, we keep a `CoerceMany` now to find the LUB of all the break expressions. Second, this `CoerceMany` is actually an `Option<CoerceMany>`, and we store `None` for loops where "break with an expression" is disallowed. This avoids silly duplicate errors about a type mismatch, since the loops pass already reports an error that the break cannot have an expression. Finally, since we now detect an invalid break target during HIR lowering, refactor `find_loop` to be infallible. Adjust tests as needed: - some spans from breaks are slightly different - break up a single loop into multiple since `CoerceMany` silences redundant and derived errors - add a ui test that we only give on error for loop-break-value 2017-03-17 15:49:53 +00:00
update tests 2018-03-03 14:59:40 +00:00			For more information about this error, try `rustc --explain E0571`.