Chris Denton

I think we should aim to be consistent with the environment unless specified otherwise. This PR does not conflict with that but neither does it obsolete that method. With this...

Specifically I don't understand how you draw this conclusion: > And as far as I can tell this small amount of dependencies doesn't actually require [or even have] the said...

Panics are implemented in terms of SEH. For msvc toolchains, rust/llvm hard codes a dependency on `_CxxThrowException` and `__CxxFrameHandler3`. See https://github.com/rust-lang/rust/blob/25b764849625cb090e8b81d12d2bb2295d073788/library/panic_unwind/src/seh.rs Even if a project doesn't use panics and the...

Panics aren't necessarily terminal (e.g. `catch_unwind`) and they are in all "normal" (not `no_std`) Rust applications even if the code paths aren't often taken. But this feels like we're getting...

I think, fundamentally, we should be trusting the user to make that determination and not overriding or ignoring their preferences unless there is a fundamental conflict. It's not the job...

Hm, these failures seem unrelated to my PR? Nothing should prevent even running tests. Looking back at other PRs it seems CI has been flaky as of late.

This PR seems reasonable to me. All it does is prefix one lib directory instead of prefixing another lib directory if a special environment variable is found. And this does...

I'm not sure I follow you. `link.exe` will not link anything unless you tell it to (this is unlike `cl.exe`). Both directories in the `LIB` environment variable and the `/LIBPATH`...

Again, I think you should open an issue about that. That code path will still exist whether or not this PR is merged.

Open an issue here, if you like. I don't think this PR is the appropriate place to flesh out things as the issue exists regardless.