rust/tests/ui/parser/range_inclusive.rs

//@ run-rustfix
// Make sure that inclusive ranges with no end point don't parse.

pub fn main() {
    for _ in 1..= {} //~ERROR inclusive range with no end
                     //~^HELP use `..` instead
}
[AUTO-GENERATED] Migrate ui tests from `//` to `//@` directives 2024-02-16 20:02:50 +00:00			`//@ run-rustfix`
test inclusive ranges Mostly copy the tests from half-open ranges, adding some more for DoubleEndedIterator and ExactSizeIterator. Also thoroughly (I think) test that the feature gates are working. 2016-01-13 01:28:29 -05:00			`// Make sure that inclusive ranges with no end point don't parse.`

			`pub fn main() {`
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 05:40:04 +00:00			`for _ in 1..= {} //~ERROR inclusive range with no end`
Ban `...X` pats, harden tests, and improve diagnostics. Also fix a bug with the span passed in `mk_range`. 2020-01-11 06:49:43 +01:00			//~^HELP use `..` instead
fatal error instead of ICE for impossible range during HIR lowering End-less ranges (`a...`) don't parse but bad syntax extensions could conceivably produce them. Unbounded ranges (`...`) do parse and are caught here. The other panics in HIR lowering are all for unexpanded macros, which cannot be constructed by bad syntax extensions. 2016-03-15 13:03:42 -04:00			`}`