Detect rustc(drivers) more precisely#1897
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1897 +/- ##
==========================================
- Coverage 31.00% 30.55% -0.46%
==========================================
Files 52 51 -1
Lines 19753 19254 -499
Branches 9506 9238 -268
==========================================
- Hits 6125 5883 -242
+ Misses 7925 7731 -194
+ Partials 5703 5640 -63 ☔ View full report in Codecov by Sentry. |
|
Aarch fails on unrelated error (installation of musl). |
Yep. It's unrelated. I'm working on the fix. Please ignore it for now. Thanks for the patience. |
13c9a17 to
a93bb87
Compare
|
I have yet to do a full review. |
6910670 to
d1ea6e3
Compare
|
I squashed all commits as they were not meant to be reviewed separately. I also updated |
d1ea6e3 to
eeffcf4
Compare
|
rebased |
eeffcf4 to
0bf8ee2
Compare
0bf8ee2 to
72ac986
Compare
|
I'll do a full review as soon as all CI steps went green |
72ac986 to
1a58db1
Compare
| if stdout.starts_with("rustc ") { | ||
| return Ok(stdout); | ||
| } | ||
| if !must_be_rust && is_like_c_compiler(&rustc_executable) { |
There was a problem hiding this comment.
I don't see the need for the must_be_rust. I do not understand why we go back to mutable state if we can use scoped Option<PathBuf> if there is a rustc-like or None, and use that to determine the full compiler path or fallback to c_compiler.
There was a problem hiding this comment.
This is to be compatible with current behavior. If name of compiler is rustc and we cannot detect it we fast fail (we do not try it for c compiler).
There was a problem hiding this comment.
That may be, but it can be expressed more concisely.
There was a problem hiding this comment.
So, should I just change behavior and simply code or express it differently (currently have no idea how)?
| "", | ||
| "gcc: error: unrecognized command-line option '-vV'; did you mean '-v'?", | ||
| )), | ||
| ); |
There was a problem hiding this comment.
Iirc, the result will be cached, so the impact of another resolution call is very small, even for small projects. Correct me if I am wrong.
There was a problem hiding this comment.
This is a principled question, if we incur much overhead for the compiler resolution with this changeset.
There was a problem hiding this comment.
I am not sure, to be honest. But if the results are cached then it should be ok.
drahnr
left a comment
There was a problem hiding this comment.
I don't particularly like the use mutable bool variables in deciding the compiler. There is an outstanding question on the efficiency of test runs and ifwe can assume -vV is unique to rust.
Even if it is not we try to parse the result and if it does not contain rustc(-drivers) specific output we know it is not rusty. |
|
moved into a different PR #1897 |
* compiler: Add an additional fallback attempt if no vanilla rustc or known cc was found Fixes #861 Co-authored-by: sagudev <[email protected]>
If we are not sure it's rustc like and we check -vV output to accept valid rustc drivers.
Fixes #861