rust/src/test/ui/impossible_range.rs

// Make sure that invalid ranges generate an error during HIR lowering, not an ICE

pub fn main() {
    ..;
    0..;
    ..1;
    0..1;
    ..=; //~ERROR inclusive range with no end
         //~^HELP bounded at the end
}

fn _foo1() {
    ..=1;
    0..=1;
    0..=; //~ERROR inclusive range with no end
          //~^HELP bounded at the end
}
test errors for malformed inclusive ranges 2016-03-15 12:02:59 -05:00			`// Make sure that invalid ranges generate an error during HIR lowering, not an ICE`

			`pub fn main() {`
			`..;`
			`0..;`
			`..1;`
			`0..1;`
Add support for `..=` syntax Add ..= to the parser Add ..= to libproc_macro Add ..= to ICH Highlight ..= in rustdoc Update impl Debug for RangeInclusive to ..= Replace `...` to `..=` in range docs Make the dotdoteq warning point to the ... Add warning for ... in expressions Updated more tests to the ..= syntax Updated even more tests to the ..= syntax Updated the inclusive_range entry in unstable book 2017-09-19 00:40:04 -05:00			`..=; //~ERROR inclusive range with no end`
Do not emit type errors on recovered blocks When a parse error occurs on a block, the parser will recover and create a block with the statements collected until that point. Now a flag stating that a recovery has been performed in this block is propagated so that the type checker knows that the type of the block (which will be identified as `()`) shouldn't be checked against the expectation to reduce the amount of irrelevant diagnostic errors shown to the user. 2017-12-14 01:05:49 -06:00			`//~^HELP bounded at the end`
			`}`

			`fn _foo1() {`
Add support for `..=` syntax Add ..= to the parser Add ..= to libproc_macro Add ..= to ICH Highlight ..= in rustdoc Update impl Debug for RangeInclusive to ..= Replace `...` to `..=` in range docs Make the dotdoteq warning point to the ... Add warning for ... in expressions Updated more tests to the ..= syntax Updated even more tests to the ..= syntax Updated the inclusive_range entry in unstable book 2017-09-19 00:40:04 -05:00			`..=1;`
			`0..=1;`
Do not emit type errors on recovered blocks When a parse error occurs on a block, the parser will recover and create a block with the statements collected until that point. Now a flag stating that a recovery has been performed in this block is propagated so that the type checker knows that the type of the block (which will be identified as `()`) shouldn't be checked against the expectation to reduce the amount of irrelevant diagnostic errors shown to the user. 2017-12-14 01:05:49 -06:00			`0..=; //~ERROR inclusive range with no end`
			`//~^HELP bounded at the end`
test errors for malformed inclusive ranges 2016-03-15 12:02:59 -05:00			`}`