| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This doesn't stabilize methods working on mutable pointers.
|
|
Adding suggestion for E0530
Closes #98974
|
|
fix ICE in ConstProp
Fixes https://github.com/rust-lang/rust/issues/96169
|
|
Track implicit `Sized` obligations in type params
When we evaluate `ty::GenericPredicates` we introduce the implicit
`Sized` predicate of type params, but we do so with only the `Predicate`
its `Span` as context, we don't have an `Obligation` or
`ObligationCauseCode` we could influence. To try and carry this
information through, we add a new field to `ty::GenericPredicates` that
tracks both which predicates come from a type param and whether that
param has any bounds already (to use in suggestions).
We also suggest adding a `?Sized` bound if appropriate on E0599.
Address part of #98539.
|
|
don't succeed `evaluate_obligation` query if new opaque types were registered
fixes #98608
fixes #98604
The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field, that will only happen if the field is generic, as only the generic parameters are checked.
I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this.
Instead, this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes`, which says that there were some opaque types that got hidden types bound, but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).
|
|
Rollup of 4 pull requests
Successful merges:
- #98533 (Add a `-Zdump-drop-tracking-cfg` debugging flag)
- #98654 (An optimization for `pest-2.1.3`)
- #98657 (Migrate some diagnostics from `rustc_const_eval` to `SessionDiagnostic`)
- #98794 (Highlight conflicting param-env candidates)
Failed merges:
- #98957 ( don't allow ZST in ScalarInt )
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=michaelwoerister
Highlight conflicting param-env candidates
This could probably be further improved by noting _why_ equivalent param-env candidates (modulo regions) leads to ambiguity.
Fixes #98786
|
|
r=Mark-Simulacrum
More derive output improvements
This PR includes:
- Some test improvements.
- Some cosmetic changes to derive output that make the code look more like what a human would write.
- Some more fundamental improvements to `cmp` and `partial_cmp` generation.
r? `@Mark-Simulacrum`
|
|
|
|
Stabilize `into_future`
https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks!
Closes https://github.com/rust-lang/rust/issues/67644
r? ``@joshtriplett``
|
|
sess: stabilize `--terminal-width` as `--diagnostic-width`
Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.
Pending agreement to stabilize, see tracking issue at #84673.
r? ```@oli-obk```
|
|
|
|
Shorten def_span of closures to just their header
Continuation of https://github.com/rust-lang/rust/pull/93967.
|
|
On partial uninit error point at where we need init
When a binding is declared without a value, borrowck verifies that all
codepaths have *one* assignment to them to initialize them fully. If
there are any cases where a condition can be met that leaves the binding
uninitialized or we attempt to initialize a field of an uninitialized
binding, we emit E0381.
We now look at all the statements that initialize the binding, and use
them to explore branching code paths that *don't* and point at them. If
we find *no* potential places where an assignment to the binding might
be missing, we display the spans of all the existing initializers to
provide some context.
Fix https://github.com/rust-lang/rust/issues/97956.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When a binding is declared without a value, borrowck verifies that all
codepaths have *one* assignment to them to initialize them fully. If
there are any cases where a condition can be met that leaves the binding
uninitialized or we attempt to initialize a field of an unitialized
binding, we emit E0381.
We now look at all the statements that initialize the binding, and use
them to explore branching code paths that *don't* and point at them. If
we find *no* potential places where an assignment to the binding might
be missing, we display the spans of all the existing initializers to
provide some context.
|
|
Suggest adding a `?Sized` bound if appropriate on E0599 by inspecting
the HIR Generics. (Fix #98539)
|
|
Add a test for #70408
closes #70408
|
|
suggest adding a derive for #[default] applied to variants
cc ``@TaKO8Ki`` as followup to #98873.
|
|
Add a test for #80471
Tests #80471, but doesn't close it, see https://github.com/rust-lang/rust/issues/80471#issuecomment-1177658967.
|
|
interpret: use AllocRange in UninitByteAccess
also use nice new format string syntax in `interpret/error.rs`, and use the `#` flag to add `0x` prefixes where applicable.
r? ``@oli-obk``
|
|
Reword comments and rename HIR visiting methods.
Sparked by this discussion in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Confused.20by.20comment.20on.20.60deep_visit_item_likes_in_module.60)
r? ``@jyn514`` ``@camsteffen``
|
|
|
|
|
|
Fix ProjectionElem validation
`TypeChecker::visit_projection_elem` was not actually being called.
|
|
|
|
|
|
|
|
|
|
|
|
Suggest using block for `extern "abi" fn` with no body
`@rustbot` modify labels: +A-diagnostics
|
|
|
|
interpret: remove support for unsized_locals
I added support for unsized_locals in https://github.com/rust-lang/rust/pull/59780 but the current implementation is a crude hack and IMO definitely not the right way to have unsized locals in MIR. It also [causes problems](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Missing.20Layout.20Check.20in.20.60interpret.2Foperand.2Ers.60.3F). and what codegen does is unsound and has been for years since clearly nobody cares (so I hope nobody actually relies on that implementation and I'll be happy if Miri ensures they do not). I think if we want to have unsized locals in Miri/MIR we should add them properly, either by having a `StorageLive` that takes metadata or by having an `alloca` that returns a pointer (making the ptr indirection explicit) or something like that.
So, this PR removes the `LocalValue::Unallocated` hack. It adds `Immediate::Uninit`, for several reasons:
- This lets us still do fairly little work in `push_stack_frame`, in particular we do not actually have to create any allocations.
- If/when I remove `ScalarMaybeUninit`, we will need something like this to have an "optimized" representation of uninitialized locals. Without this we'd have to put uninitialized integers into the heap!
- const-prop needs some way to indicate "I don't know the value of this local'; it used to use `LocalValue::Unallocated` for that, now it can use `Immediate::Uninit`.
There is still a fundamental difference between `LocalValue::Unallocated` and `Immediate::Uninit`: the latter is considered a regular local that you can read from and write to, it just has a more optimized representation when compared with an actual `Allocation` that is fully uninit. In contrast, `LocalValue::Unallocated` had this really odd behavior where you would write to it but not read from it. (This is in fact what caused the problems mentioned above.)
While at it I also did two drive-by cleanups/improvements:
- In `pop_stack_frame`, do the return value copying and local deallocation while the frame is still on the stack. This leads to better error locations being reported. The old errors were [sometimes rather confusing](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Cron.20Job.20Failure.202022-06-24/near/287445522).
- Deduplicate `copy_op` and `copy_op_transmute`.
r? `@oli-obk`
|
|
r=cjgillot
Replace some `guess_head_span` with `def_span`
This patch fixes a part of #97417.
r? `@cjgillot`
|
|
|
|
|
|
Rename the `--output-width` flag to `--diagnostic-width` as this appears
to be the preferred name within the compiler team.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Rename the `--terminal-width` flag to `--output-width` as the behaviour
doesn't just apply to terminals (and so is slightly less accurate).
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
also use nice new format string syntax in interpret/error.rs
|
|
|
|
|
|
|
|
assert Scalar sanity
With https://github.com/rust-lang/rust/pull/96814 having landed, finally our `Scalar` layouts have the invariants they deserve. :)
|
