| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fixes #41849. Problem was that evaluating the constant expression
required evaluating a trait, which would equate types, which would
request variance information, which it would then discard. However,
computing the variance information would require determining the type of
a field, which would evaluate the constant expression.
(This problem will potentially arise *later* as we move to more sophisticated
constants, however, where we need to check subtyping. We can tackle that
when we come to it.)
|
|
This seems both to be a safe, conservative choice,
and it sidesteps the cycle in #41936.
Fixes #41936.
|
|
|
|
Fixes #41604.
|
|
|
|
`try_index_step` does not resolve type variables by itself and would
fail otherwise. Also harden the failure path in `confirm` to cause less
confusing errors.
|
|
|
|
Remove items that are unstable and deprecated
This removes unstable items that have been deprecated for more than one cycle.
- Since 1.16.0, `#![feature(enumset)]`
- All of `mod collections::enum_set`
- Since 1.15.0, `#![feature(borrow_state)]`
- `cell::BorrowState`
- `RefCell::borrow_state()`
- Since 1.15.0, `#![feature(is_unique)]`
- `Rc::is_unique()` (made private like `Arc::is_unique()`)
- Since 1.15.0, `#![feature(rc_would_unwrap)]`
- `Rc::would_wrap()`
- Since 1.13.0, `#![feature(binary_heap_extras)]`
- `BinaryHeap::push_pop()`
- `BinaryHeap::replace()`
- Since 1.12.0, `#![feature(as_unsafe_cell)]`
- `Cell::as_unsafe_cell()`
- `RefCell::as_unsafe_cell()`
- Since 1.12.0, `#![feature(map_entry_recover_keys)]`
- `btree_map::OccupiedEntry::remove_pair()`
- `hash_map::OccupiedEntry::remove_pair()`
- Since 1.11.0, `#![feature(float_extras)]`
- `Float::nan()`
- `Float::infinity()`
- `Float::neg_infinity()`
- `Float::neg_zero()`
- `Float::zero()`
- `Float::one()`
- `Float::integer_decode()`
- `f32::integer_decode()`
- `f32::ldexp()`
- `f32::frexp()`
- `f32::next_after()`
- `f64::integer_decode()`
- `f64::ldexp()`
- `f64::frexp()`
- `f64::next_after()`
- Since 1.11.0, `#![feature(zero_one)]`
- `num::Zero`
- `num::One`
|
|
[unstable, deprecated since 1.11.0]
|
|
[unstable, deprecated since 1.11.0]
|
|
[unstable, deprecated since 1.13.0]
|
|
[unstable, deprecated since 1.16.0]
|
|
|
|
The main changes around rustc::ty::Layout::struct and rustc_trans:adt:
* Added primitive_align field which stores alignment before repr align
* Always emit field padding when generating the LLVM struct fields
* Added methods for adjusting field indexes from the layout index to the
LLVM struct field index
The main user of this information is rustc_trans::adt::struct_llfields
which determines the LLVM fields to be used by LLVM, including padding
fields.
|
|
|
|
Ban registering obligations during InferCtxt snapshots.
Back in #33852, a flag was added to `InferCtxt` to prevent rolling back a snapshot if obligations were added to some `FulfillmentContext` during the snapshot, to prevent leaking fresh inference variables (created during that snapshot, so their indices would get reused) in obligations, which could ICE or worse.
But that isn't enough in the long run, as type-checking ends up relying on success implying that eager side-effects are fine, and while stray obligations *do* get caught nowadays, those errors prevent, e.g. the speculative coercions from #37658, which *have to* be rolled back *even* if they succeed.
We can't just allow those obligations to stay around though, because we end up, again, in ICEs or worse.
Instead, this PR modifies `lookup_method_in_trait_adjusted` to return `InferOk` containing the obligations that `Autoderef::finalize_as_infer_ok` can propagate to deref coercions.
As there shouldn't be *anything* left that registers obligations during snapshots, it's completely banned.
r? @nikomatsakis @arielb1
|
|
:vis matcher for macro_rules
Resurrection of @DanielKeep's implementation posted with [RFC 1575](https://github.com/rust-lang/rfcs/pull/1575).
@jseyfried was of the opinion that this doesn't need an RFC.
Needed before merge:
- [x] sign-off from @DanielKeep since I stole his code
- [x] feature gate
- [x] docs
|
|
Specialize Vec::from_elem to use calloc
Fixes #38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired.
I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #38723.
|
|
Do not desugar if-let-else to match arm guards
Fixes #41272
Changed the desugaring code
**Before**
```rust
match <sub_expr> {
<pat> => <body>,
[_ if <else_opt_if_cond> => <else_opt_if_body>,]
_ => [<else_opt> | ()]
}
```
**After**
```rust
match <sub_expr> {
<pat> => <body>,
_ => [<else_opt> | ()]
}
```
With this fix, it doesn't cause E0301
|
|
|
|
|
|
|
|
|
|
I've added some explicit tests that negative impls are allowed to
overlap, and also to make sure that the feature doesn't interfere with
specialization. I've not added an explicit test for positive overlapping
with negative, as that's already tested elsewhere.
|
|
|
|
This patch allows overlap to occur between any two impls of a trait for
traits which have no associated items.
Several compile-fail tests around coherence had to be changed to add at
least one item to the trait they test against.
Ref #29864
|
|
Implement global_asm!() (RFC 1548)
This is a first attempt. ~~One (potential) problem I haven't solved is how to handle multiple usages of `global_asm!` in a module/crate. It looks like `LLVMSetModuleInlineAsm` overwrites module asm, and `LLVMAppendModuleInlineAsm` is not provided in LLVM C headers 😦~~
I can provide more detail as needed, but honestly, there's not a lot going on here.
r? @eddyb
CC @Amanieu @jackpot51
Tracking issue: #35119
|
|
|
|
rustc_typeck: consolidate adjustment composition
Instead of having `write_adjustment` overwrite the previous adjustment, have `apply_adjustment` compose a new adjustment on top of the previous one. This is important because `NeverToAny` adjustments can be present on expressions during coercion.
Fixes #41213.
r? @nikomatsakis
|
|
Fixes #41213.
|
|
Fix invalid 128-bit division on 32-bit target (#41228)
The bug of #41228 is a typo, this line: https://github.com/rust-lang/rust/blob/1dca19ae3fd195fa517e326a39bfee729da7cadb/src/libcompiler_builtins/lib.rs#L183
```rust
// 1 <= sr <= u64::bits() - 1
q = n.wrapping_shl(64u32.wrapping_sub(sr));
```
The **64** should be **128**.
(Compare with https://github.com/rust-lang-nursery/compiler-builtins/blob/280d19f1127aa80739f4179152b11a5f7d36d79f/src/int/udiv.rs#L213-L214:
```rust
// 1 <= sr <= <hty!($ty)>::bits() - 1
q = n << (<$ty>::bits() - sr);
```
Or compare with the C implementation https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/udivmodti4.c#L113-L116
```c
/* 1 <= sr <= n_udword_bits - 1 */
/* q.all = n.all << (n_utword_bits - sr); */
q.s.low = 0;
q.s.high = n.s.low << (n_udword_bits - sr);
```
)
Added a bunch of randomly generated division test cases to try to cover every described branch of `udivmodti4`.
|
|
Windows builder croaked. This change tries to fix that by actually
calling the global_asm-defined function so the symbol doesn't get
optimized away, if that is in fact what was happening.
Additionally, we provide an empty main() for non-x86 arches.
|
|
r=arielb1
Handle subtyping in inference through obligations
We currently store subtyping relations in the `TypeVariables` structure as a kind of special case. This branch uses normal obligations to propagate subtyping, thus converting our inference variables into normal fallback. It also does a few other things:
- Removes the (unstable, outdated) support for custom type inference fallback.
- It's not clear how we want this to work, but we know that we don't want it to work the way it currently does.
- The existing support was also just getting in my way.
- Fixes #30225, which was caused by the trait caching code pretending type variables were normal unification variables, when indeed they were not (but now are).
There is one fishy part of these changes: when computing the LUB/GLB of a "bivariant" type parameter, I currently return the `a` value. Bivariant type parameters are only allowed in a very particular situation, where the type parameter is only used as an associated type output, like this:
```rust
pub struct Foo<A, B>
where A: Fn() -> B
{
data: A
}
```
In principle, if one had `T=Foo<A, &'a u32>` and `U=Foo<A, &'b u32>` and (e.g.) `A: for<'a> Fn() -> &'a u32`, then I think that computing the LUB of `T` and `U` might do the wrong thing. Probably the right behavior is just to create a fresh type variable. However, that particular example would not compile (because the where-clause is illegal; `'a` does not appear in any input type). I was not able to make an example that *would* compile and demonstrate this shortcoming, and handling the LUB/GLB was mildly inconvenient, so I left it as is. I am considering whether to revisit this or what.
I have started a crater run to test the impact of these changes.
|
|
|
|
Added test cases to cover all special-cased branches of udivmodti4.
|
|
When we are generalizing a super/sub-type, we have to replace type
variables with a fresh variable (and not just region variables). So if
we know that `Box<?T> <: ?U`, for example, we instantiate `?U` with
`Box<?V>` and then relate `Box<?T>` to `Box<?V>` (and hence require that
`?T <: ?V`).
This change has some complex interactions, however:
First, the occurs check must be updated to detect constraints like `?T
<: ?U` and `?U <: Box<?T>`. If we're not careful, we'll create a
never-ending sequence of new variables. To address this, we add a second
unification set into `type_variables` that tracks type variables related
through **either** equality **or** subtyping, and use that during the
occurs-check.
Second, the "fudge regions if ok" code was expecting no new type
variables to be created. It must be updated to create new type variables
outside of the probe. This is relatively straight-forward under the new
scheme, since type variables are now independent from one another, and
any relations are moderated by pending subtype obliations and so forth.
This part would be tricky to backport though.
cc #18653
cc #40951
|
|
This just limits ourselves to the "old school" defaults: diverging
variables and integer variables.
|
|
based on 32-bit or 64-bit architecture.
|
|
|
|
field reordering.
|
|
cstore: return an immutable borrow from `visible_parent_map`
This prevents an ICE when `visible_parent_map` is called multiple times, for example when an item referenced in an impl signature is imported from an `extern crate` statement occurs within an impl.
Fixes #41053.
r? @eddyb
|
|
Don't warn about `char` comparisons in constexprs
Fixes #40970 by evaluating const-exprs for comparisons on `char`s properly.
|
