incr.comp.: Fix two problems with HIR hashing.
Fixes https://github.com/rust-lang/rust/issues/45469.
This PR fixes two small problems:
* Overflow checks are always enabled in a constant context, so we need to hash spans of potentially overflowing operations. (Eventually I'd like to handle spans differently so we don't have to make HIR hashing know so much about things like this.)
* The HIR map collector had a bug where it would assign the `DepNode::Hir` instead of the corresponding `DepNode::HirBody` in some nested contexts.
r? @nikomatsakis
Fix duplicate display of error E0502
Ref. Repeated "mutable/immutable borrow" error messages #42106.
This PR modifies the return type of [`report_error_if_loan_conflicts_with_restriction`](0f0f5db465/src/librustc_borrowck/borrowck/check_loans.rs (L398-L403)) so the result can be checked in [`report_error_if_loans_conflict`](0f0f5db465/src/librustc_borrowck/borrowck/check_loans.rs (L377-L396)). This is done to prevent displaying a duplicate of the error message E0502 which is referenced in #42106.
The output of compiling:
```rust
fn do_something<T>(collection: &mut Vec<T>) {
let _a = &collection;
collection.swap(1, 2);
}
fn main() {}
```
is now
```bash
$ rustc src/test/compile-fail/issue-42106.rs
error[E0502]: cannot borrow `*collection` as mutable because `collection` is also borrowed as immutable
--> src/test/compile-fail/issue-42106.rs:13:5
|
12 | let _a = &collection;
| ---------- immutable borrow occurs here
13 | collection.swap(1, 2);
| ^^^^^^^^^^ mutable borrow occurs here
14 | }
| - immutable borrow ends here
error: aborting due to 2 previous errors
```
r? @estebank
Implement RFC 1861: Extern types
A few notes :
- Type parameters are not supported. This was an unresolved question from the RFC. It is not clear how useful this feature is, and how variance should be treated. This can be added in a future PR.
- `size_of_val` / `align_of_val` can be called with extern types, and respectively return 0 and 1. This differs from the RFC, which specified that they should panic, but after discussion with @eddyb on IRC this seems like a better solution.
If/when a `DynSized` trait is added, this will be disallowed statically.
- Auto traits are not implemented by default, since the contents of extern types is unknown. This means extern types are `!Sync`, `!Send` and `!Freeze`. This seems like the correct behaviour to me.
Manual `unsafe impl Sync for Foo` is still possible.
- This PR allows extern type to be used as the tail of a struct, as described by the RFC :
```rust
extern {
type OpaqueTail;
}
#[repr(C)]
struct FfiStruct {
data: u8,
more_data: u32,
tail: OpaqueTail,
}
```
However this is undesirable, as the alignment of `tail` is unknown (the current PR assumes an alignment of 1). Unfortunately we can't prevent it in the general case as the tail could be a type parameter :
```rust
#[repr(C)]
struct FfiStruct<T: ?Sized> {
data: u8,
more_data: u32,
tail: T,
}
```
Adding a `DynSized` trait would solve this as well, by requiring tail fields to be bound by it.
- Despite being unsized, pointers to extern types are thin and can be casted from/to integers. However it is not possible to write a `null<T>() -> *const T` function which works with extern types, as I've explained here : https://github.com/rust-lang/rust/issues/43467#issuecomment-321678621
- Trait objects cannot be built from extern types. I intend to support it eventually, although how this interacts with `DynSized`/`size_of_val` is still unclear.
- The definition of `c_void` is unmodified
Improve diagnostics when list of tokens has incorrect separators
Make `parse_seq_to_before_tokens` more resilient to error conditions. Where possible it is better if it can consume up to the final bracket before returning. This change improves the diagnostics in a couple of situations:
```
struct S(pub () ()); // omitted separator
use std::{foo. bar}; // used a similar but wrong separator
```
Fixes#44339
r? @petrochenkov
Don't emit the same compiler diagnostic twice.
This PR makes the compiler filter out diagnostic messages that have already been emitted during the same compilation session.
Avoid unnecessary copies of arguments that are simple bindings
Initially MIR differentiated between arguments and locals, which
introduced a need to add extra copies assigning the argument to a
local, even for simple bindings. This differentiation no longer exists,
but we're still creating those copies, bloating the MIR and LLVM IR we
emit.
Additionally, the current approach means that we create debug info for
both the incoming argument (marking it as an argument), and then
immediately shadow it a local that goes by the same name. This can be
confusing when using e.g. "info args" in gdb, or when e.g. a debugger
with a GUI displays the function arguments separately from the local
variables, especially when the binding is mutable, because the argument
doesn't change, while the local variable does.
Initially MIR differentiated between arguments and locals, which
introduced a need to add extra copies assigning the argument to a
local, even for simple bindings. This differentiation no longer exists,
but we're still creating those copies, bloating the MIR and LLVM IR we
emit.
Additionally, the current approach means that we create debug info for
both the incoming argument (marking it as an argument), and then
immediately shadow it a local that goes by the same name. This can be
confusing when using e.g. "info args" in gdb, or when e.g. a debugger
with a GUI displays the function arguments separately from the local
variables, especially when the binding is mutable, because the argument
doesn't change, while the local variable does.
Correct misspelling in error text: re-assignment => reassignment
[reassignment is the correct spelling](https://www.thefreedictionary.com/reassignment) rather than re-assignment; this error message looks silly in the book next to text trying to be grammatically correct :-/
Will this cause any stability/backcompat type issues?
Use 128 bit instead of Symbol for crate disambiguator
As discussed on gitter, this changes `crate_disambiguator` from Strings to what they are represented as, a 128 bit number.
There's also one bit I think also needs to change, but wasn't 100% sure how: [create_root_def](f338dba297/src/librustc/hir/map/definitions.rs (L468-L482)). Should I change `DefKey::root_parent_stable_hash` to accept `Fingerprint` as crate_disambiguator to quickly combine the hash of `crate_name` with the new 128 bit hash instead of a string for a disambiguator?
r? @michaelwoerister
EDIT: Are those 3 tests `mir-opt` failing, because the hash is different, because we calculate it a little bit differently (storing directly instead of hashing the hex-string representation)? Should it be updated like in #45319?
Improve diagnostic of E0119 with extern crate, try to print the conflicting impl.
Closes#27403.
Closes#23563.
Should improve #23980.
The diagnostic now looks like:
```
error[E0119]: conflicting implementations of trait `std::convert::Into<_>` for type `GenX<_>`:
--> $DIR/issue-27403.rs:15:1
|
15 | / impl<S> Into<S> for GenX<S> {
16 | | fn into(self) -> S {
17 | | self.inner
18 | | }
19 | | }
| |_^
|
= note: conflicting implementation in crate `core`:
- impl<T, U> std::convert::Into<U> for T
where U: std::convert::From<T>;
error: aborting due to previous error
```
Move Generics from MethodSig to TraitItem and ImplItem
As part of `rust-impl-period/WG-compiler-traits`, we want to "lift" `Generics` from `MethodSig` into `TraitItem` and `ImplItem`. This is in preparation for adding associated type generics. (https://github.com/rust-lang/rust/issues/44265#issuecomment-331172238)
Currently this change is only made in the AST. In the future, it may also impact the HIR. (Still discussing)
To understand this PR, it's probably best to start from the changes to `ast.rs` and then work your way to the other files to understand the far reaching effects of this change.
r? @nikomatsakis
Now that we are visiting things in a different order during lowering,
adding parameters winds up affecting the HirIds assigned to thinks in
the method body, whereas it didn't before. We could fix this by
reordering the order in which we visit `generics` during lowering, but
this feels very fragile. Seems better to just let typeck tables be
dirty here.
rustc: Add `_imp_` symbols later in compilation
On MSVC targets rustc will add symbols prefixed with `_imp_` to LLVM modules to
"emulate" dllexported statics as that workaround is still in place after #27438
hasn't been solved otherwise. These statics, however, were getting gc'd by
ThinLTO accidentally which later would cause linking failures.
This commit updates the location we add such symbols to happen just before
codegen to ensure that (a) they're not eliminated by the optimizer and (b) the
optimizer doesn't even worry about them.
Closes#45347
