Compiletest panics on custom lldb version

[Manishearth]

My system has a custom version of lldb on it, and the lldb version string does not match the expected format. I'm not sure if I can share the exact version string but the first line is somehting like lldb version foo5-bar (revision somehash)

Check compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: Empty }', src/tools/compiletest/src/main.rs:978:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I feel like I should be able to run the uitests without needing the precise lldb version. I tried to override this by passing --lldb-version to ./x.py but it doesn't seem to accept that parameter.

[Mark-Simulacrum]

Hm, I think we recently landed a PR relaxing some of this parsing a bit. But it may be that we should relax it more; is the version you expect to pass extractable from the --version results?

I don't think x.py should accept it directly as an option, but perhaps we can add it to config.toml.

[Manishearth]

@Mark-Simulacrum No, there is no version number, just a hash. I have a patch that fixes this acceptably for my use case (makes the function return None), unsure if that's the best behavior here.

[Mark-Simulacrum]

Hm, making it return none presumably means we just skip the lldb tests? It might be better to move the validation later, such that --exclude src/test/debuginfo-lldb or something like it works to skip this check as well.

We don't really have a principled story about ignoring vs. erroring, but I'm trying to be more cautious over time about silent acceptance.

[Manishearth]

Hm, making it return none presumably means we just skip the lldb tests? It might be better to move the validation later, such that --exclude src/test/debuginfo-lldb or something like it works to skip this check as well.

That would also work for me.

That function does return None in a couple other cases already though.