When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be impenetrable to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.
This only applies when Microsoft's link tool is expected. Not `lld-link` or other MSVC compatible linkers.
Adjust the zero check in `RawVec::grow`.
This was supposed to land as part of #72227. (I wish `git push` would
abort when you have uncommited changes.)
r? @Amanieu
Continue lowering for unsupported async generator instead of returning an error.
This way the hir is "valid" and we can remove one more call to
`opt_node_id_to_hir_id` but an error is still emitted.
This is another partial fix for #71104
r? @eddyb
Make `fold` standalone.
`fold` is currently implemented via `try_fold`, but implementing it
directly results in slightly less LLVM IR being generated, speeding up
compilation of some benchmarks.
r? @cuviper
Suggest fixes and add error recovery for `use foo::self`
Fixes#63741.
I have implemented 2 suggestions on how to fix a `use foo::self` import, however I feel like showing them both might be too verbose.
Additionally, I have also implemented error recovery as [menitoned](https://github.com/rust-lang/rust/issues/63741#issuecomment-602391091) by @comex.
I believe r? @estebank deals with diagnostics.
linker: More systematic handling of CRT objects
Document which kinds of `crt0.o`-like objects we link and in which cases, discovering bugs in process.
`src/librustc_target/spec/crt_objects.rs` is the place to start reading from.
This PR also automatically contains half of the `-static-pie` support (https://github.com/rust-lang/rust/pull/70740), because that's one of the six cases that we need to consider when linking CRT objects.
This is a breaking change for custom target specifications that specify CRT objects.
Closes https://github.com/rust-lang/rust/issues/30868
Update cargo
9 commits in cb06cb2696df2567ce06d1a39b1b40612a29f853..500b2bd01c958f5a33b6aa3f080bea015877b83c
2020-05-08 21:57:44 +0000 to 2020-05-18 17:12:54 +0000
- Handle LTO with an rlib/cdylib crate type (rust-lang/cargo#8254)
- Gracefully handle errors during a build. (rust-lang/cargo#8247)
- Update `im-rc` to 15.0.0 (rust-lang/cargo#8255)
- Fix `cargo update` with unused patch. (rust-lang/cargo#8243)
- Rephrased error message for disallowed sections in virtual workspace (rust-lang/cargo#8200)
- Ignore broken console output in some situations. (rust-lang/cargo#8236)
- Expand error message to explain that a string was found (rust-lang/cargo#8235)
- Add context to some fs errors. (rust-lang/cargo#8232)
- Move SipHasher to an isolated module. (rust-lang/cargo#8233)
...when determining what locals are live.
A local cannot be borrowed before it is `storage_live` and
`MaybeBorrowedLocals` already invalidates borrows on `StorageDead`.
Likewise, a local cannot be initialized before it is marked StorageLive
and is marked as uninitialized after `StorageDead`.
The generator transform needs to inspect all possible dataflow states.
This can be done with half the number of bitset union operations if we
can assume that the relevant analyses do not use "before" effects.
Instead of using a bespoke dataflow analysis, `MaybeRequiresStorage`,
for computing locals that need to be stored across yield points and that
have conflicting storage, use a combination of simple, generally
applicable dataflow analyses. In this case, the formula for locals
that are live at a yield point is:
live_across_yield := (live & init) | (!movable & borrowed)
and the formula for locals that require storage (and thus may conflict
with others) at a given point is:
requires_storage := init | borrowed
`init` is `MaybeInitializedLocals`, a direct equivalent of
`MaybeInitializedPlaces` that works only on whole `Local`s. `borrowed`
and `live` are the pre-existing `MaybeBorrowedLocals` and
`MaybeLiveLocals` analyses respectively.
