thread 'rustc' panicked at 'begin <= end (2 <= 0) when slicing

[dwrensha]

I'm seeing an internal compiler error on the input "\n#!B\n" (found by fuzz-rustc):

$ cat main.rs

#!B
$ rustc main.rs
thread 'rustc' panicked at 'begin <= end (2 <= 0) when slicing `
#!B
`', /rustc/b2e36e6c2d229126b59e892c9147fbb68115d292/src/libcore/str/mod.rs:1920:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.44.0-nightly (b2e36e6c2 2020-04-22) running on x86_64-unknown-linux-gnu

This issue has been assigned to @rcoh via this comment.

[dwrensha]

Error is similar to #70677. @rcoh is this possibly related?

[rcoh]

Will do a quick investigation and find out

[LeSeulArtichaut]

Backtrace :

stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:515
  12: rust_begin_unwind
             at src/libstd/panicking.rs:419
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:111
  14: core::str::slice_error_fail
             at src/libcore/str/mod.rs:0
  15: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
  16: rustc_parse::lexer::StringReader::next_token
  17: rustc_parse::lexer::tokentrees::TokenTreesReader::parse_all_token_trees
  18: rustc_parse::lexer::tokentrees::<impl rustc_parse::lexer::StringReader>::into_token_trees
  19: rustc_parse::maybe_file_to_stream
  20: rustc_parse::maybe_source_file_to_parser
  21: rustc_parse::new_parser_from_file
  22: rustc_parse::parse_crate_from_file
  23: rustc_session::utils::<impl rustc_session::session::Session>::time
  24: rustc_interface::passes::parse
  25: rustc_interface::queries::Queries::parse
  26: rustc_interface::interface::run_compiler_in_existing_thread_pool
  27: scoped_tls::ScopedKey<T>::set
  28: rustc_ast::attr::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

The error probably originates from:

rust/src/librustc_parse/lexer/mod.rs

Line 98 in 235938d

let text: &str = &self.src[start_src_index..self.end_src_index];

[rcoh]

@rustbot claim

[spastorino]

Assigning P-low as discussed as part of the Prioritization Working Group process and removing I-prioritize.

[LeSeulArtichaut]

Should we add the need-bisection label?

[rcoh]

this also looks suspicious: https://github.com/rust-lang/rust/pull/71372/files

[rcoh]

OK, I've determined the root cause. https://github.com/rust-lang/rust/pull/71372/files changes the shebang handling to strip whitespace -- the intention was to strip internal whitespace to fix #70528 , but it's also stripping external whitespace which (I believe) is a bug.

[dwrensha]

It looks like this was fixed by #71634, so I think it can be closed.