| Age | Commit message (Collapse) | Author | Lines |
|
Backport 46112 fix to beta
Its probably easiest to focus on the diff rather than the commit series.
If you prefer I could squash them, but I figured preserving the cherry-picking will make it easier to relate what has happened here to what happens on the `master` branch.
Note: This is a backport of *just* #46838. It does not include #46708 (which we may end up wanting to revert).
Fix #46112
|
|
This reverts commit f50fd075c2555d8511ccee8a7fe7aee3f2c45e14, reversing
changes made to 5041b3bb3d953a14f32b15d1e41341c629acae12.
|
|
The reason we see `core::` even after visiting the `std` crate first
is the special case code that looks like this:
```rust
Entry::Occupied(mut entry) => {
// If `child` is defined in crate `cnum`, ensure
// that it is mapped to a parent in `cnum`.
if child.krate == cnum && entry.get().krate != cnum {
entry.insert(parent);
}
}
```
This causes items to be associated with the crates they were
originally defined in, even if we had encountered them during the
traversal of an earlier crate.
(Having said that, I am not clear on why this same logic does not
apply when both #46708 and #46838 have been applied. But at this
point, I am just happy to have a plausible explanation for why we see
`core::foo::bar` in the output for these tests, and want to focus on
getting this fix for #46112 backported to beta.)
|
|
|
|
Sorting by crate-num should ensure that we favor `std::foo::bar` over
`any_other_crate::foo::bar`.
Interestingly, *this* change had a much larger impact on our internal
test suite than PR #46708 (which was my original fix to #46112).
----
(This is cherry-pick of aa030dd3deb438c688c85c32eb75d009378c5f12 to beta.)
|
|
Refactor type memory layouts and ABIs, to be more general and easier to optimize.
To combat combinatorial explosion, type layouts are now described through 3 orthogonal properties:
* `Variants` describes the plurality of sum types (where applicable)
* `Single` is for one inhabited/active variant, including all C `struct`s and `union`s
* `Tagged` has its variants discriminated by an integer tag, including C `enum`s
* `NicheFilling` uses otherwise-invalid values ("niches") for all but one of its inhabited variants
* `FieldPlacement` describes the number and memory offsets of fields (if any)
* `Union` has all its fields at offset `0`
* `Array` has offsets that are a multiple of its `stride`; guarantees all fields have one type
* `Arbitrary` records all the field offsets, which can be out-of-order
* `Abi` describes how values of the type should be passed around, including for FFI
* `Uninhabited` corresponds to no values, associated with unreachable control-flow
* `Scalar` is ABI-identical to its only integer/floating-point/pointer "scalar component"
* `ScalarPair` has two "scalar components", but only applies to the Rust ABI
* `Vector` is for SIMD vectors, typically `#[repr(simd)]` `struct`s in Rust
* `Aggregate` has arbitrary contents, including all non-transparent C `struct`s and `union`s
Size optimizations implemented so far:
* ignoring uninhabited variants (i.e. containing uninhabited fields), e.g.:
* `Option<!>` is 0 bytes
* `Result<T, !>` has the same size as `T`
* using arbitrary niches, not just `0`, to represent a data-less variant, e.g.:
* `Option<bool>`, `Option<Option<bool>>`, `Option<Ordering>` are all 1 byte
* `Option<char>` is 4 bytes
* using a range of niches to represent *multiple* data-less variants, e.g.:
* `enum E { A(bool), B, C, D }` is 1 byte
Code generation now takes advantage of `Scalar` and `ScalarPair` to, in more cases, pass around scalar components as immediates instead of indirectly, through pointers into temporary memory, while avoiding LLVM's "first-class aggregates", and there's more untapped potential here.
Closes #44426, fixes #5977, fixes #14540, fixes #43278.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Layout::StructWrappedNullablePointer.
|
|
Remove left over dead code from suggestion diagnostic refactoring
More cleanups after #41876 and #45741
|
|
|
|
integrate MIR type-checker with NLL inference
This branch refactors NLL type inference so that it uses the MIR type-checker to gather constraints. Along the way, it also refactors how region constraints are gathered in the normal inference context mildly. The new setup is like this:
- What used to be `region_inference` is split into two parts:
- `region_constraints`, which just collects up sets of constraints
- `lexical_region_resolve`, which does the iterative, lexical region resolution
- When `resolve_regions_and_report_errors` is invoked, the inference engine converts the constraints into final values.
- In the MIR type checker, however, we do not invoke this method, but instead periodically take the region constraints and package them up for the NLL solver to use later.
- This allows us to track when and where those constraints were incurred.
- We also remove the central fulfillment context from the MIR type checker, instead instantiating new fulfillment contexts at each point. This allows us to capture the set of obligations that occurred at a particular point, and also to ensure that if the same obligation arises at two points, we will enforce the region constraints at both locations.
- The MIR type checker is also enhanced to instantiate late-bound-regions with fresh variables and handle a few other corner cases that arose.
- I also extracted some of the 'outlives' logic from the regionck, which will be needed later (see future work) to handle the type-outlives relationships.
One concern I have with this branch: since the MIR type checker is used even without the `-Znll` switch, I'm not sure if it will impact performance. One simple fix here would be to only enable the MIR type-checker if debug-assertions are enabled, since it just serves to validate the MIR. Longer term I hope to address this by improving the interface to the trait solver to be more query-based (ongoing work).
There is plenty of future work left. Here are two things that leap to mind:
- **Type-region outlives.** Currently, the NLL solver will ICE if it is required to handle a constraint like `T: 'a`. Fixing this will require a small amount of refactoring to extract the implied bounds code. I plan to follow a file-up bug on this (hopefully with mentoring instructions).
- **Testing.** It's a good idea to enumerate some of the tricky scenarios that need testing, but I think it'd be nice to try and parallelize some of the actual test writing (and resulting bug fixing):
- Same obligation occurring at two points.
- Well-formedness and trait obligations of various kinds (which are not all processed by the current MIR type-checker).
- More tests for how subtyping and region inferencing interact.
- More suggestions welcome!
r? @arielb1
|
|
Rollup of 6 pull requests
- Successful merges: #45951, #45973, #45984, #45993, #46005, #46010
- Failed merges:
|
|
|
|
|
|
|
|
Set short-message feature unstable
Fixes #45995.
r? @nrc
|
|
check_unsafety: fix unused unsafe block duplication
The duplicate error message is later removed by error message
deduplication, but it still appears on beta and is still a bug.
r? @eddyb
|
|
|
|
|
|
|
|
|
|
First some background:
To the compiler, the following two signatures in the trait vs the impl
are the same.
```rust
trait Foo {
fn foo(&self, &impl Debug);
}
impl Foo for () {
fn foo<U: Debug>(&self, x: &U) { ... }
}
```
We do not want to allow this, and so we add a new error and check.
The check just tests that all paramters 'syntheticness' match up. As
during collection, the impl Trait parameters are transformed into
anonymous synthetic generics.
Furthermore, causes a check for unused type parameters to be skipped in
check_bounds_are_used if there is already a TyError. Thus, an unused
input will not trigger `type parameter unused` errors.
Update the one test that checked for this error in the case of
a TyError.
|
|
|
|
The duplicate error message is later removed by error message
deduplication, but it still appears on beta and is still a bug
|
|
deduplicate projection error (E0271) messages
The `ErrorId` variant takes a u16 so that `DiagnosticMessageId` can retain
its `Copy` status (the present author's first choice having been the "EXXX"
code as a string).
The duplicated "type mismatch resolving `{}`" literal is unfortunate, but
the `struct_span_err!` macro (which we want to mark that error code as
used) is fussy about taking a literal, and the one-time-diagnostics set
needs an owned string.
This is concerning #33941 and probably #45805!
r? @estebank
|
|
MIR-borrowck: fix diagnostics for closures
Emit notes for captured variables in the same manner as AST borrowck.
```
error[E0499]: cannot borrow `x` as mutable more than once at a time (Ast)
--> $DIR/borrowck-closures-two-mut.rs:24:24
|
23 | let c1 = to_fn_mut(|| x = 4);
| -- - previous borrow occurs due to use of `x` in closure
| |
| first mutable borrow occurs here
24 | let c2 = to_fn_mut(|| x = 5); //~ ERROR cannot borrow `x` as mutable more than once
| ^^ - borrow occurs due to use of `x` in closure
| |
| second mutable borrow occurs here
25 | }
| - first borrow ends here
error[E0499]: cannot borrow `x` as mutable more than once at a time (Mir)
--> $DIR/borrowck-closures-two-mut.rs:24:24
|
23 | let c1 = to_fn_mut(|| x = 4);
| -- - previous borrow occurs due to use of `x` in closure
| |
| first mutable borrow occurs here
24 | let c2 = to_fn_mut(|| x = 5); //~ ERROR cannot borrow `x` as mutable more than once
| ^^ - borrow occurs due to use of `x` in closure
| |
| second mutable borrow occurs here
25 | }
| - first borrow ends here
```
Fixes #45362.
|
|
The `ErrorId` variant takes a u16 so that `DiagnosticMessageId` can retain
its `Copy` status (the present author's first choice having been the "EXXX"
code as a string).
The duplicated "type mismatch resolving `{}`" literal is unfortunate, but
the `struct_span_err!` macro (which we want to mark that error code as
used) is fussy about taking a literal, and the one-time-diagnostics set
needs an owned string.
This is concerning #33941 and probably #45805!
|
|
|
|
#42701
|
|
Implement arbitrary_self_types
r? @arielb1
cc @nikomatsakis
Partial implementation of #44874. Supports trait and struct methods with arbitrary self types, as long as the type derefs (transitively) to `Self`. Doesn't support raw-pointer `self` yet.
Methods with non-standard self types (i.e. anything other than `&self, &mut self, and Box<Self>`) are not object safe, because dynamic dispatch hasn't been implemented for them yet.
I believe this is also a (partial) fix for #27941.
|
|
r=eddyb
adjust closure kind based on the guarantor's upvar note
Fixes #30046.
r? @eddyb
|
|
|
|
restore move out dataflow, add report of move out errors
fix https://github.com/rust-lang/rust/issues/45363
r? @arielb1
|
|
Make positional argument error in format! clearer
r? @estebank
Fixes #44954
|
|
resolve: Use same rules for disambiguating fresh bindings in `match` and `let`
Resolve `Unit` as a unit struct pattern in
```rust
struct Unit;
let Unit = x;
```
consistently with
```rust
match x {
Unit => {}
}
```
It was previously an error.
(The change also applies to unit variants and constants.)
Fixes https://users.rust-lang.org/t/e0530-cannot-shadow-unit-structs-what-in-the-earthly-what/13054
(This particular change doesn't depend on a fix for the issue mentioned in https://users.rust-lang.org/t/e0530-cannot-shadow-unit-structs-what-in-the-earthly-what/13054/4)
cc @rust-lang/lang
r? @nikomatsakis
|
|
fixes to MIR effectck
r? @eddyb
beta-nominating because regression (MIR effectck is new)
|
|
Allow a trailling comma in assert_eq/ne macro
From Rust beginners IRC:
<???> It sure does annoy me that assert_eq!() does not accept a trailing comma after the last argument.
<???> ???: File an issue against https://github.com/rust-lang/rust and CC @rust-lang/libs
Figured that might as well submit it. Will become insta-stable after merging (danger zone).
cc @rust-lang/libs
|
|
Fix help for duplicated names: `extern crate (...) as (...)`
On the case of duplicated names caused by an `extern crate` statement
with a rename, don't include the inline suggestion, instead using a span
label with only the text to avoid incorrect rust code output.
Fix #45829.
|
|
|
|
|
|
|
|
|
|
|
|
Detect `=` -> `:` typo in let bindings
When encountering a let binding type error, attempt to parse as
initializer instead. If successful, it is likely just a typo:
```rust
fn main() {
let x: Vec::with_capacity(10);
}
```
```
error: expected type, found `10`
--> file.rs:3:31
|
3 | let x: Vec::with_capacity(10, 20);
| -- ^^
| ||
| |help: did you mean assign here?: `=`
| while parsing the type for `x`
```
Fix #43703.
|
|
On the case of duplicated names caused by an `extern crate` statement
with a rename, don't include the inline suggestion, instead using a span
label with only the text to avoid incorrect rust code output.
|