| Age | Commit message (Collapse) | Author | Lines |
|---|
|
These errors will be triggered before the MIR const-checker runs,
causing all other errors to be silenced. They are now checked in the
`const-{if,loop}` tests.
|
|
|
|
|
|
Refactor slice pattern usefulness checking
As a follow up to https://github.com/rust-lang/rust/pull/65874, this PR changes how variable-length slice patterns are handled in usefulness checking. The objectives are: cleaning up that code to make it easier to understand, and paving the way to handling fixed-length slices more cleverly too, for https://github.com/rust-lang/rust/issues/53820.
Before this, variable-length slice patterns were eagerly expanded into a union of fixed-length slices. Now they have their own special constructor, which allows expanding them a bit more lazily.
As a nice side-effect, this improves diagnostics.
This PR shows a slight performance improvement, mostly due to https://github.com/rust-lang/rust/pull/66129/commits/149792b6080f40875c0072aae378a0eb31d23df0. This will probably have to be reverted in some way when we implement or-patterns.
|
|
This change makes error and warning annotations mandatory in UI tests.
The only exception are tests that use error patterns to match compiler
output and don't have any annotations.
|
|
We bailed out of `QualifyAndPromoteConsts` immediately if the
`min_const_fn` checks failed, which sometimes resulted in additional,
spurious errors since promotion was skipped.
We now do promotion in a completely separate pass, so this is no longer
an issue.
|
|
r=eddyb
Remove promotion candidate gathering and checking from `qualify_consts.rs`
This makes promotion candidate gathering and checking the exclusive domain of `promote_consts`, but the `QualifyAndPromoteConsts` pass is still responsible for both const-checking and creating promoted MIR fragments.
This should not be merged until the beta branches on Nov. 5.
r? @eddyb
|
|
consistent handling of missing sysroot spans
Due to https://github.com/rust-lang/rust/issues/53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue.
I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since https://github.com/rust-lang/rust/pull/64151. Cc @estebank @varkor
|
|
Update some build-pass ui tests to use check-pass where applicable
Helps with issue https://github.com/rust-lang/rust/issues/62277.
|
|
Miri: Refactor to_scalar_ptr out of existence
`to_scalar_ptr` is somewhat subtle as it just throws away the 2nd component of a `ScalarPair` if there is one -- without any check if this is truly a pointer or so. And indeed we used it wrong on two occasions!
So I fixed those two, and then refactored things such that everyone calls `ref_to_mplace` instead (which they did anyway, I just moved up the calls), which is the only place that should interpret a `ScalarPair` as a wide ptr -- and it checks the type first. Thus we can remove `to_scalar_ptr` and `to_meta`.
r? @oli-obk
|
|
Fix promotion in a `const` when projections are present
Resolves #65727.
This marks the entire local as "needs promotion" when only a projection of that local appears in a promotable context. This should only affect promotion in a `const` or `static`, not in a `fn` or `const fn`, which is handled in `promote_consts.rs`.
r? @eddyb
|
|
The old const-checker conservatively reset qualifs when
`IsNotPromotable` was in the return place. Unfortunately, named
variables have `IsNotPromotable`, so this could cause promotion to fail.
This should work now.
|
|
|
|
This improves error messages by indicating when slices above a certain
lengths have not been matched. Previously, we would only report examples
of such lengths, but of course never all of them.
|
|
fix Miri offset_from
This is needed to make https://github.com/rust-lang/miri/pull/1032 pass.
|
|
These errors are suboptimal, but they will be fixed by the new
`check_consts` pass.
|
|
|
|
|
|
|
|
Previously, this worked in `fn`s but not `const`s or `static`s.
|
|
Make <*const/mut T>::offset_from `const fn`
This reenables offset_of cc @mjbshaw after https://github.com/rust-lang/rust/pull/63075 broke it
|
|
|
|
|
|
Stabilize `const_constructor`
# Stabilization proposal
I propose that we stabilize `#![feature(const_constructor)]`.
Tracking issue: https://github.com/rust-lang/rust/issues/61456
Version target: 1.40 (2019-11-05 => beta, 2019-12-19 => stable).
## What is stabilized
### User guide
Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called:
```rust
const fn make_options() {
// These already work because they are special cased:
Some(0);
(Option::Some)(1);
// These also work now:
let f = Option::Some;
f(2);
{Option::Some}(3);
<Option<_>>::Some(5);
}
```
### Motivation
Consistency with other `const fn`. Consistency between syntactic path forms.
This should also ensure that constructors implement `const Fn` traits and can be coerced to `const fn` function pointers, if they are introduced.
## Tests
* [ui/consts/const_constructor/const-construct-call.rs](https://github.com/rust-lang/rust/blob/0d75ab2293a106eb674ac01860910cfc1580837e/src/test/ui/consts/const_constructor/const-construct-call.rs) - Tests various syntactic forms, use in both `const fn` and `const` items, and constructors in both the current and extern crates.
* [ui/consts/const_constructor/const_constructor_qpath.rs](https://github.com/rust-lang/rust/blob/1850dfcdabf8258a1f023f26c2c59e96b869dd95/src/test/ui/consts/const_constructor/const_constructor_qpath.rs) - Tests that type qualified paths to enum variants are also considered to be `const fn`.(#64247)
r? @oli-obk
Closes #61456
Closes #64247
|
|
|
|
|
|
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
|
|
make is_power_of_two a const function
This makes `is_power_of_two` a const function by using `&` instead of short-circuiting `&&`; Rust supports bitwise `&` for `bool` and short-circuiting is not required in the existing expression.
I don't think this needs a const-hack label as I don't find the changed code less readable, if anything I prefer that it is clearer that short circuiting is not used.
@oli-obk
|
|
Remove `borrowck_graphviz_postflow` from test
Resolves #65071 (again).
Sorry. I've added a commit hook to prevent this from happening in the future.
r? @petrochenkov
|
|
|
|
add test for calling non-const fn
The good news is that there is an error. But I expected to see [this error](https://github.com/rust-lang/rust/blob/9578272d681c8691ca2ff3f5c4230b491bc1c694/src/librustc_mir/const_eval.rs#L346) surface. @oli-obk any idea why that message is not shown anywhere?
r? @oli-obk
|
|
Use structured suggestion for restricting bounds
When a trait bound is not met and restricting a type parameter would
make the restriction hold, use a structured suggestion pointing at an
appropriate place (type param in param list or `where` clause).
Account for opaque parameters where instead of suggesting extending
the `where` clause, we suggest appending the new restriction:
`fn foo(impl Trait + UnmetTrait)`. Fix #64565, fix #41817, fix #24354,
cc #26026, cc #37808, cc #24159, fix #37138, fix #24354, cc #20671.
|
|
|
|
|
|
|
|
[const-prop] Handle remaining MIR Rvalue cases
r? @oli-obk
|
|
r=eddyb
Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut`
Resolves #65394.
This hack disables the validator mismatch ICE in cases where a `MutBorrow` error has been emitted by both validators, but they don't agree on the number of `LiveDrop` errors.
The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a `LiveDrop` error on the following code.
```rust
const _: Vec<i32> = {
let mut x = Vec::new();
let px = &mut x as *mut _;
let y = x;
unsafe { ptr::write(px, Vec::new()); }
y
};
```
This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a `LiveDrop` error for `x` upon exit from the initializer. `x` is not actually dropped, so I think this is correct? A proper fix for this would require a new `MaybeInitializedLocals` dataflow analysis or maybe a relaxation of the existing `IndirectlyMutableLocals` one.
r? @RalfJung
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
|
|
Return `false` from `needs_drop` for all zero-sized arrays.
Resolves #65348.
This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving #65348 and #64945, but obviously it has much broader implications.
|
|
|
|
Compute the layout of uninhabited structs
fixes #64506
r? @eddyb
|
|
|
|
Report `CONST_ERR` lint in external macros
fixes #65300
fixes #61058
r? @oli-obk
|
|
|
