rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables
Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a `bool` argument, but there it means something unrelated).
Also see https://github.com/rust-lang/rust/pull/8855#discussion_r374392128.
I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to `true` when LLVM *could* optimize them away, so this PR should have no effect anyway.
r? @michaelwoerister or @nagisa cc @hanna-kruppe @nikomatsakis
Derive Clone + Eq for std::string::FromUtf8Error
Implement `Clone` and `Eq` for `std::string::FromUtf8Error`.
Both the inner `Vec<u8>` and `std::str::Utf8Error` are also `Clone + Eq`, so I don't see why we shouldn't derive them on `FromUtf8Error` as well.
(impl are insta-stable, requiring FCP from T-libs.)
Add an option to use LLD to link the compiler on Windows platforms
Based on https://github.com/rust-lang/rust/pull/68609.
Using LLD is good way to improve compile times on Windows since `link.exe` is quite slow. The time for `x.py build --stage 1 src/libtest` goes from 0:12:00 to 0:08:29. Compile time for `rustc_driver` goes from 226.34s to 18.5s. `rustc_macros` goes from 28.69s to 7.7s. The size of `rustc_driver` is also reduced from 83.3 MB to 78.7 MB.
r? @Mark-Simulacrum
Rollup of 7 pull requests
Successful merges:
- #68718 (Move `rustc_hir::def_id` to `rustc_span::def_id`)
- #68834 (Fix and test implementation of BTreeMap's first/last_entry, pop_first/last)
- #68857 (perf: Reduce Vec allocations in normalization by passing &mut Vec)
- #68918 (Don't use the word "unwrap" to describe "unwrap" methods)
- #68946 (Mark several functions and methods in core::cmp as #[must_use])
- #68958 (Clean up E0277 and E0282 explanations)
- #68960 (codegen: misc cleanups around debuginfo scopes and locations.)
Failed merges:
r? @ghost
When suggesting associated fn with type parameters, include in the structured suggestion
Address #50734.
```
error[E0046]: not all trait items implemented, missing: `foo`, `bar`, `baz`
--> file.rs:14:1
|
14 | impl TraitA<()> for S {
| ^^^^^^^^^^^^^^^^^^^^^ missing `foo`, `bar`, `baz` in implementation
|
= help: implement the missing item: `fn foo<T>(_: T) -> Self where T: TraitB, TraitB::Item = A { unimplemented!() }`
= help: implement the missing item: `fn bar<T>(_: T) -> Self { unimplemented!() }`
= help: implement the missing item: `fn baz<T>(_: T) -> Self where T: TraitB, <T as TraitB>::Item: std::marker::Copy { unimplemented!() }`
```
It doesn't work well for associated types with `ty::Predicate::Projection`s as we need to resugar `T: Trait, Trait::Assoc = K` → `T: Trait<Assoc = K>`.
Initial implementation of `#![feature(move_ref_pattern)]`
Following up on #45600, under the gate `#![feature(move_ref_pattern)]`, `(ref x, mut y)` is allowed subject to restrictions necessary for soundness. The match checking implementation and tests for `#![feature(bindings_after_at)]` is also adjusted as necessary.
Closes#45600.
Tracking issue: #68354.
r? @matthewjasper
codegen: misc cleanups around debuginfo scopes and locations.
See each commit message. Most of these seem to be leftovers from the transition to MIR codegen.
r? @nagisa cc @bjorn3
Mark several functions and methods in core::cmp as #[must_use]
These functions and methods aren't mutating functions and ignoring the result of them is likely a bug in the user's code.
Don't use the word "unwrap" to describe "unwrap" methods
It's tautological, and "unwrap" is essentially Rust-specific jargon.
I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed.
This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description:
> "Returns the contained `Some/Ok` value [or ...]."
It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks.
Previous: https://github.com/rust-lang/rust/pull/68849
perf: Reduce Vec allocations in normalization by passing &mut Vec
Complicates the code a bit but allocation/freeing were a few percent of the overall runtime in trait heavy code.
Fix and test implementation of BTreeMap's first/last_entry, pop_first/last
Properly implement and test `first_entry` & `last_entry` to fix problem report #68829
Move `rustc_hir::def_id` to `rustc_span::def_id`
This will allow `HygieneData` to refer to `DefId` and `DefIndex`, which
will enable proper serialization of Span hygiene information.
This also reduces the number of things imported from `rustc_hir`, which
might make it easier to remove dependencies on it.
rustc_codegen_ssa: don't treat inlined variables as debuginfo arguments.
Fixes#67586 by limiting `ArgumentVariable` special-casing to `VarDebugInfo` entries that are in `OUTERMOST_SOURCE_SCOPE`, i.e. the function's own argument scope.
That excludes `VarDebugInfo` from inlined callees, which can also point to the caller's argument locals.
This is a snippet from the optimized MIR (including inlining) of the testcase:
```rust
fn foo(_1: usize) -> usize {
debug bar => _1; // in scope 0 at ./example.rs:2:12: 2:15
let mut _0: usize; // return place in scope 0 at ./example.rs:2:27: 2:32
scope 1 {
debug x => _1; // in scope 1 at /rustc/9ed29b6ff6aa2e048b09c27af8f62ee3040bdb37/src/libcore/convert/mod.rs:106:26: 106:27
}
```
`scope 1` is from inlining the `identity` call, and `debug x => _1;` comes from the body of `core::convert::identity`, so they are now ignored for the purposes of determining the `ArgumentVariable` debuginfo associated to `_1`.
