You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rustc compiler panic prints to stdout - breaks RLS comms #48816
With this bug I'm less interested in the rustc bugs themselves rather that they can cause output to stdout. Doing so is unacceptable for the Rls as it breaks jsonrpc, and in a way that is not currently recoverable by vscode-jsonrpc library (used by atom & vscode RLS clients).
Is there any way we can minimise the possibility of rustc printing stdout in RLS usage?
This looks like we're printing the --help message after a panic, which is kind of weird. @rust-lang/compiler any idea why that would happen? @alexheretic does that look like what is happening?
@nrc that's exactly what it looks like. I'm getting this consistently too, with the stdout each panic now requires an Rls & Rls client restart :(. The panic themselves seem to occur at certain situations when the code won't compile, ie I encounter it eventually by editing code.
changed the title [-]Rustc compiler panic prints to stdout - breaks Rls comms[/-][+]Rustc compiler panic prints to stdout - breaks RLS comms[/+]on Mar 13, 2018
Ok clearly the panic comes from rustc_driver::run_compiler called by Rls. By looking at librustc_driver/lib.rs I can see the usage function is the cause of the offending stdout.
usage is called by handle_options which prints this when the args are empty. Rls does not call run_compiler without arguments.
However, added a couple of weeks ago by #48266 is what strongly seems to be source of this issue:
// librustc_driver/lib.rs
.../// Get a list of extra command-line flags provided by the user, as strings.////// This function is used during ICEs to show more information useful for/// debugging, since some ICEs only happens with non-default compiler flags/// (and the users don't always report them).
fn extra_compiler_flags() -> Option<(Vec<String>, bool)> {letmut args = Vec::new();for arg in env::args_os(){
args.push(arg.to_string_lossy().to_string());}let matches = ifletSome(matches) = handle_options(&args){ ...
As this code uses env::args_os() it is assuming the compiler is the program. Whereas in this case Rls has been started without arguments.
It makes sense to return None from this function in the case there are no arguments, printing help at this stage isn't intended I imagine.
Reacted by Danny Fritz, Esteban Kuber, Michael Woerister and Emily Albini
Activity
nrc commentedon Mar 9, 2018
This looks like we're printing the
--helpmessage after a panic, which is kind of weird. @rust-lang/compiler any idea why that would happen? @alexheretic does that look like what is happening?alexheretic commentedon Mar 10, 2018
@nrc that's exactly what it looks like. I'm getting this consistently too, with the stdout each panic now requires an Rls & Rls client restart :(. The panic themselves seem to occur at certain situations when the code won't compile, ie I encounter it eventually by editing code.
michaelwoerister commentedon Mar 12, 2018
Weird indeed
:)@alexheretic, maybe the full stack trace of the panic might help diagnose the problem. Can you provide a screenshot showing the stack frames above
12?alexheretic commentedon Mar 12, 2018
The traces themselves seemed very similar to those reported in rust-lang/rls#754. I'll add my trace next time I encounter one.
nikomatsakis commentedon Mar 13, 2018
(What is a "RI"?)
oli-obk commentedon Mar 13, 2018
rls😆 I wondered the same thing when I first saw the title[-]Rustc compiler panic prints to stdout - breaks Rls comms[/-][+]Rustc compiler panic prints to stdout - breaks RLS comms[/+]alexheretic commentedon Mar 13, 2018
That is something I can clarify easily.
nikomatsakis commentedon Mar 13, 2018
Can we reproduce this running from the command line?
nikomatsakis commentedon Mar 13, 2018
Should be plenty of ICEs to pick from in the repo :)
alexheretic commentedon Mar 13, 2018
Here's the output of one from just now
And the stdout
alexheretic commentedon Mar 13, 2018
Could rls be executing rustc after a panic in such a way to cause stdout? Though I don't imagine it's running
rustc --help...alexheretic commentedon Mar 13, 2018
Ok clearly the panic comes from
rustc_driver::run_compilercalled by Rls. By looking at librustc_driver/lib.rs I can see theusagefunction is the cause of the offending stdout.usageis called byhandle_optionswhich prints this when the args are empty. Rls does not call run_compiler without arguments.However, added a couple of weeks ago by #48266 is what strongly seems to be source of this issue:
As this code uses
env::args_os()it is assuming the compiler is the program. Whereas in this case Rls has been started without arguments.It makes sense to return
Nonefrom this function in the case there are no arguments, printing help at this stage isn't intended I imagine.michaelwoerister commentedon Mar 14, 2018
@pietroalbini, it seems that the ICE message PR had some unintended side-effects
:)