Repository navigation
compiletest: may truncate compiler output before trying to parse it as json #96229
Description
Activity
- addedE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.A-testsuiteArea: The testsuite used to check the correctness of rustcArea: The testsuite used to check the correctness of rustc
on Apr 19, 2022 I think this is somewhat a duplicate of #94322 and #92211.
It might be good to consolidate these issues, and come up with a specific suggestion on how to improve it. The limit needs to be there to prevent OOM, and also as a indicator that perhaps rustc is emitting too much data (as #94327 resolved). So I suspect what is desired is a better way to display the error. I haven't thought about it myself, but I think that should be easy to improve.
- removedE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
on Apr 20, 2022 Got it, removed E-easy.
I feel like at least a part of this problem is in the fact that the truncation happens indiscriminately at a byte boundary. And another part is that the failure mode is non-deterministic (paths and such can have varying lengths.)
If the intent is to make “too much output” a failure mode, then we should just straight up fail the test, I feel. Possibly kill/SIGPIPE the compilation process when it exceeds the amount of output bytes but don't truncate the output itself when showing it to the user…?
Alternatively, for JSONL(ines) truncating on line boundaries would make things not fail as terribly. Not to mention, the rendered output is duplicated among other information with JSON output and a test will likely be interested in only parts of it, which will make truncation kick in earlier in some instances than others, so maybe giving an opportunity to
mapthe output in a streaming fashion would help?Also hit this due to #96362 (comment) on my local machine...
Opened a PR to remove the nondeterminism based on the length of the checkout path, which should at least alleviate the problem (abbreviations would still happen, but at least they'd show up on CI): #96551
- added a commit that references this issue
on Sep 15, 2023
Running a
uitest will eventually invoke the following function:rust/src/tools/compiletest/src/read2.rs
Lines 48 to 57 in 4ca19e0
through
rust/src/tools/compiletest/src/runtest.rs
Lines 1772 to 1780 in 4ca19e0
which can truncate a long output from the compiler. The problem is that UI tests ask the compiler to output its output as json and then attempts to parse it later, for example here:
rust/src/tools/compiletest/src/runtest.rs
Line 3114 in 4ca19e0
which can fail due to truncation and output very difficult to investigate output in e.g. CI.
Reference: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/Legacy.20PM.20removal/near/279479951