| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Rollup of 10 pull requests
- Successful merges: #44192, #44199, #44202, #44203, #44205, #44207, #44209, #44223, #44230, #44231
- Failed merges:
|
|
rustc: Fix reachability with cross-crate generators
Same solution as in f2df1857
Closes #44181
|
|
Lambda expressions honor no struct literal restriction
This is a fix for #43412 if we decide that it is indeed a bug :)
closes #43412
|
|
Same solution as in f2df1857
Closes #44181
|
|
Forward-compatibly deny drops in constants if they *could* actually run.
This is part of #40036, specifically the checks for user-defined destructor invocations on locals which *may not* have been moved away, the motivating example being:
```rust
const FOO: i32 = (HasDrop {...}, 0).1;
```
The evaluation of constant MIR will continue to create `'static` slots for more locals than is necessary (if `Storage{Live,Dead}` statements are ignored), but it shouldn't be misusable.
r? @nikomatsakis
|
|
Make fields of `Span` private
I actually tried to intern spans and benchmark the result<sup>*</sup>, and this was a prerequisite.
This kind of encapsulation will be a prerequisite for any other attempt to compress span's representation, so I decided to submit this change alone.
The issue https://github.com/rust-lang/rust/issues/43088 seems relevant, but it looks like `SpanId` won't be able to reuse this interface, unless the tables are global (like interner that I tried) and are not a part of HIR.
r? @michaelwoerister anyway
<sup>*</sup> Interning means 2-3 times more space is required for a single span, but duplicates are free. In practice it turned out that duplicates are not *that* common, so more memory was wasted by interning rather than saved.
|
|
|
|
This fixes a few cases of inference misses, some of them regressions
caused by the impl selected for a method not being immediately evaluated.
|
|
|
|
|
|
|
|
|
|
Fixes issue #43205: ICE in Rvalue::Len evaluation.
- fixes evaluation of array length for zero-sized type referenced by rvalue operand.
- adds test to verify fix.
*Cause of the issue*.
Zero-sized aggregates are handled as operands, not lvalues. Therefore while visiting `Assign` statement by `LocalAnalyser`, `mark_as_lvalue()` is not called for related `Local`. This behaviour is controlled by `rvalue_creates_operand()` method.
As result it causes error later, when rvalue operand is evaluated in `trans_rvalue_operand()` while handling `Rvalue::Len` case. Array length evaluation invokes `trans_lvalue()` which expects referenced `Local` to be value, not operand.
*How it is fixed*.
In certain cases result of `Rvalue::Len` can be evaluated without calling
`trans_lvalue()`. Method `evaluate_array_len()` is introduced to handle length
evaluation for zero-sized types referenced by Locals.
*Some concerns*.
- `trans_lvalue()` has two other entry points in `rvalue.rs`: it is invoked while handling `Rvalue::Ref` and `Rvalue::Discriminant`. There is a chance those may produce the same issue, but I've failed to write a specific test that leads to this.
- `evaluate_array_len()` performs the same check (matches lvalue and `Local`), which is performed again in `trans_lvalue()`. Without changing `trans_lvalue()` signature to make it aware that caller deals with rvalue, it seems there is no cheap solution to avoid this check.
|
|
This is test for #42918.
To reproduce bug you need machine with arm cpu and compile with optimization.
I tried with rustc 1.19.0-nightly (3d5b8c626 2017-06-09),
if compile test with -C opt-level=3 for target=arm-linux-androideabi
and run on "Qualcomm MSM 8974 arm cpu" then assert fails,
if compile and run with -C opt-level=2 it gives segmentation fault.
So I add `compile-flags: -O`.
With rustc 1.19.0 (0ade33941 2017-07-17) all works fine.
Closes #42918
|
|
|
|
- fixes evaluation of array length for zero-sized type referenced by
rvalue operand.
- adds test to verify fix.
Cause of the issue.
Zero-sized aggregates are handled as operands, not lvalues. Therefore while
visiting Assign statement by LocalAnalyser, mark_as_lvalue() is not called for
related Local. This behaviour is controlled by rvalue_creates_operand() method.
As result it causes error later, when rvalue operand is evaluated in
trans_rvalue_operand() while handling Rvalue::Len case. Array length evaluation
invokes trans_lvalue() which expects referenced Local to be value, not operand.
How it is fixed.
In certain cases result of Rvalue::Len can be evaluated without calling
trans_lvalue(). Method evaluate_array_len() is introduced to handle length
evaluation for zero-sized types referenced by Locals.
|
|
Fix little-endian assumptions in run-pass/union/union-basic
None
|
|
|
|
Register fn-ptr coercion obligations out of a snapshot
Fixes #43923.
beta-nominating because regression.
r? @eddyb
|
|
Make sure crates not opting in to staged_api don't use staged_api
This also fixes the problem that with `-Zforce-unstable-if-unmarked` set, crates could not use `#[deprecated]`.
If you prefer, I can instead submit another version which just fixes this problem, but still allows the staged API attributes for all crates when `-Zforce-unstable-if-unmarked` is set. I have prepared that at <https://github.com/RalfJung/rust/tree/staged2>. As yet another alternative, @alexcrichton suggested to turn this error into a lint, but that seems to be much more work, so is it worth it?
Cc @alexcrichton #43975
|
|
|
|
Generate builtin impls for `Clone`
This fixes a long-standing ICE and limitation where some builtin types implement `Copy` but not `Clone` (whereas `Clone` is a super trait of `Copy`).
However, this PR has a few side-effects:
* `Clone` is now marked as a lang item.
* `[T; N]` is now `Clone` if `T: Clone` (currently, only if `T: Copy` and for `N <= 32`).
* `fn foo<'a>() where &'a mut (): Clone { }` won't compile anymore because of how bounds for builtin traits are handled (e.g. same thing currently if you replace `Clone` by `Copy` in this example). Of course this function is unusable anyway, an error would pop as soon as it is called.
Hence, I'm wondering wether this PR would need an RFC...
Also, cc-ing @nikomatsakis, @arielb1.
Related issues: #28229, #24000.
|
|
|
|
Fixes #43923.
|
|
Both new tests currently fail
|
|
When walking parents for lints we want to be sure to hit `let` statements which
can have attributes, so hook up these statements in the HIR map.
Closes #43910
|
|
|
|
Fixes #43692.
|
|
|
|
|
|
rustc: Fix `unknown_lints` next to an unknown lint
The lint refactoring in #43522 didn't account for `#[allow(unknown_lints)]`
happening at the same node as an unknown lint itself, so this commit updates the
handling to ensure that the local set of lint configuration being built is
queried before looking at the chain of lint levels.
Closes #43809
|
|
|
|
remove the "defaulted unit" type bit during writeback
The defaulted unit bit is only relevant for the surrounding inference
context, and can cause trouble, including spurious lints and ICEs,
outside of it.
Fixes #43853.
r? @eddyb
|
|
|
|
|
|
|
|
Fixes #28229.
Fixes #24000.
|
|
The defaulted unit bit is only relevant for the surrounding inference
context, and can cause trouble, including spurious lints and ICEs,
outside of it.
Fixes #43853.
|
|
|
|
Fix for issue #39827
*Cause of the issue*
While preparing for `trans_intrinsic_call()` invoke arguments are processed with `trans_argument()` method which excludes zero-sized types from argument list (to be more correct - all arguments for which `ArgKind` is `Ignore` are filtered out). As result `volatile_store()` intrinsic gets one argument instead of expected address and value.
*How it is fixed*
Modification of the `trans_argument()` method may cause side effects, therefore change was implemented in `volatile_store()` intrinsic building code itself. Now it checks function signature and if it was specialised with zero-sized type, then emits `C_nil()` instead of accessing non-existing second argument.
|
|
The lint refactoring in #43522 didn't account for `#[allow(unknown_lints)]`
happening at the same node as an unknown lint itself, so this commit updates the
handling to ensure that the local set of lint configuration being built is
queried before looking at the chain of lint levels.
Closes #43809
|
|
- removes warnings introduced in changeset 0cd3587
- makes documentation more neat and grammatically correct
|
|
|
|
# Conflicts:
# src/librustc_mir/build/scope.rs
|
|
For box expressions, use NZ drop instead of a free block
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
r? @nagisa
|
|
|
|
|
|
Rollup of 18 pull requests
- Successful merges: #43176, #43632, #43650, #43712, #43715, #43721, #43739, #43741, #43744, #43747, #43752, #43760, #43773, #43779, #43783, #43791, #43793, #43795
- Failed merges:
|
