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 }}
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.
Unsetting RUST_LOG doesn't work when the logger has already been initialized (in the first call to rls), rustc/cargo in-process calls will be guided by the original RUST_LOG value. Out of process calls (e.g., dependencies compilation) do benefit from clear_env_rust_log as the new process initializes its log (e.g., rustc_log::run).
Not sure if there's a way to reconfigure an already initialized log.
Interestingly (and somewhat related to this but not a responsibility of clear_env_rust_log),
RUSTC_LOG=debug rls --cli
produces the rustc log for the in-process (primary packages) compilation. I would have expected those to happen with RUST_LOG (even after the RUST_ to RUSTC_ transition) because clear_env_rust_log uses the same unset env.var mechanism, but they seem to appear (no matter the filter) only with the RUSTC_ variant.
(edit: actually, the output generated in the RUSTC_ case, which contains mostly MIR and codegen information, might not come particularly from in-process rustc calls and I may be confounding sources)
(edit 2: yes, it seems the output is mainly parallel codegen spawned processes, similar to what's described in the first part of the issue)
The text was updated successfully, but these errors were encountered:
To reproduce:
Unsetting
RUST_LOG
doesn't work when the logger has already been initialized (in the first call torls
),rustc
/cargo
in-process calls will be guided by the originalRUST_LOG
value. Out of process calls (e.g., dependencies compilation) do benefit fromclear_env_rust_log
as the new process initializes its log (e.g.,rustc_log::run
).Not sure if there's a way to reconfigure an already initialized log.
Interestingly (and somewhat related to this but not a responsibility ofclear_env_rust_log
),produces therustc
log for the in-process (primary packages) compilation. I would have expected those to happen withRUST_LOG
(even after theRUST_
toRUSTC_
transition) becauseclear_env_rust_log
uses the same unset env.var mechanism, but they seem to appear (no matter the filter) only with theRUSTC_
variant.(edit: actually, the output generated in the
RUSTC_
case, which contains mostly MIR andcodegen
information, might not come particularly from in-processrustc
calls and I may be confounding sources)(edit 2: yes, it seems the output is mainly parallel
codegen
spawned processes, similar to what's described in the first part of the issue)The text was updated successfully, but these errors were encountered: