Better handling of lib defaults #40022
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
So it looks like running |
|
Ah, possibly this is a rustup issue. I'll investigate more tomorrow. |
|
Looks great to me, thanks @wagenet! Could you also add a test for this functionality? |
|
@alexcrichton how do you recommend testing this? I couldn't find any existing tests for the command line flags, though I might just be missing them. |
|
@wagenet oh I'm just thinking like a run-pass test which passes |
wagenet
force-pushed
the
lib-defaults
branch
from
b71e748
to
69c5359
Compare
|
@bors: r+ |
|
📌 Commit 69c5359 has been approved by |
|
So I've verified that this all works in my local app and fixes the bug I was encountering. However, I haven't yet been able to figure out good tests. The ones here don't really test properly. |
|
@wagenet ah that's ok, let's leave this to bors |
Better handling of lib defaults r? @alexcrichton
Better handling of lib defaults r? @alexcrichton
Rollup of 28 pull requests - Successful merges: #39859, #39864, #39888, #39903, #39905, #39914, #39945, #39950, #39953, #39961, #39980, #39988, #39993, #39995, #40019, #40020, #40022, #40024, #40025, #40026, #40027, #40031, #40035, #40037, #40038, #40064, #40069, #40086 - Failed merges: #39927, #40008, #40047
r? @alexcrichton