| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fixes #75144
|
|
Point to a move-related span when pointing to closure upvars
Fixes #75904
When emitting move/borrow errors, we may point into a closure to
indicate why an upvar is used in the closure. However, we use the
'upvar span', which is just an arbitrary usage of the upvar. If the
upvar is used in multiple places (e.g. a borrow and a move), we may end
up pointing to the borrow. If the overall error is a move error, this
can be confusing.
This PR tracks the span that caused an upvar to become captured by-value
instead of by-ref (assuming that it's not a `move` closure). We use this
span instead of the 'upvar' span when we need to point to an upvar usage
during borrow checking.
|
|
change offset from u32 to u64
References #71696
r? @oli-obk
(closed the earlier pr because the rebase got messed up)
|
|
Fixes #75904
When emitting move/borrow errors, we may point into a closure to
indicate why an upvar is used in the closure. However, we use the
'upvar span', which is just an arbitrary usage of the upvar. If the
upvar is used in multiple places (e.g. a borrow and a move), we may end
up pointing to the borrow. If the overall error is a move error, this
can be confusing.
This PR tracks the span that caused an upvar to become captured by-value
instead of by-ref (assuming that it's not a `move` closure). We use this
span instead of the 'upvar' span when we need to point to an upvar usage
during borrow checking.
|
|
Be consistent when describing a move as a 'partial' in diagnostics
When an error occurs due to a partial move, we would use the world
"partial" in some parts of the error message, but not in others. This
commit ensures that we use the word 'partial' in either all or none of
the diagnostic messages.
Additionally, we no longer describe a move out of a `Box` via `*` as
a 'partial move'. This was a pre-existing issue, but became more
noticable when the word 'partial' is used in more places.
|
|
Refactor the partitioning module to make it easier to introduce new algorithms
I've split the `librustc_mir::monomorphize::partitioning` module into a few files and introduced a `Partitioner` trait which allows us to decouple the partitioning algorithm from the code which integrates it into the query system. This should allow us to introduce new partitioning algorithms much more easily. I've also gone ahead and added a `-Z` flag to control which algorithm is used (currently there is only the `default`).
I left a few comments in places where things might be improved further.
r? @pnkfelix cc @rust-lang/wg-incr-comp
|
|
Stabilize Range[Inclusive]::is_empty
I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhausted isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with the stable `contains` method, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based `is_empty` plans, as these inherent ones are preferred in name resolution
https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty
https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty
Closes #48111
|
|
|
|
|
|
|
|
I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhaused isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with now-stable `contains`, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based is_empty plans, as the inherent ones are preferred in name resolution
|
|
This commit adjusts the naming of various lang items so that they are
consistent and don't include prefixes containing the target or
"LangItem". In addition, lang item variants are no longer exported from
the `lang_items` module.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
additional context for the recursive call.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
|
|
|
|
|
|
This will allow us to prototype different partitioning schemes without
adding a lot of extra conditionals everywhere.
|
|
Rollup of 8 pull requests
Successful merges:
- #75672 (Move to intra-doc links for task.rs and vec.rs)
- #75702 (Clean up E0759 explanation)
- #75703 (Enable stack-overflow detection on musl for non-main threads)
- #75710 (Fix bad printing of const-eval queries)
- #75716 (Upgrade Emscripten on CI to 1.39.20 )
- #75731 (Suppress ty::Float in MIR comments of ty::Const)
- #75733 (Remove duplicated alloc vec bench push_all_move)
- #75743 (Rename rustc_lexer::TokenKind::Not to Bang)
Failed merges:
r? @ghost
|
|
Already covered by MIR constant comments
|
|
Check that we don't use `Rvalue::Aggregate` after the deaggregator
fixes #75481
r? @wesleywiser
cc @RalfJung (modified the validator)
|
|
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
|
|
|
|
|
|
davidtwco:polymorphization-predicate-simplification-correction, r=eddyb
polymorphize: if any param in a predicate is used, then all are used
Addresses [review](https://github.com/rust-lang/rust/pull/75518#discussion_r470907646) [comments](https://github.com/rust-lang/rust/pull/75518#discussion_r470907865) [from](https://github.com/rust-lang/rust/pull/75518#discussion_r470908188) @eddyb in #75518 that I didn't get to resolve before bors merged.
This PR modifies polymorphization's handling of predicates so that if any generic parameter is used in a predicate then all parameters in that predicate are used.
r? @eddyb
|
|
Moved coverage counter injection from BasicBlock to Statement.
As discussed on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Implement.20LLVM-compatible.20source-based.20cod.20compiler-team.23278
|
|
|
|
|
|
|
|
|
|
|
|
Suppress verbose MIR comments for trivial types
Addresses #74508
This is my first contribution to the Rust project! Please let me know if anything needs revising, I'm happy to make changes.
|
|
Rollup of 8 pull requests
Successful merges:
- #75389 (attempt to improve span_label docs)
- #75392 (Add `as_uninit`-like methods to pointer types and unify documentation of `as_ref` methods)
- #75464 (Move to intra doc links for ascii.rs and panic.rs)
- #75578 (Allowing raw ptr dereference in const fn)
- #75613 (Add explanation for `&mut self` method call when expecting `-> Self`)
- #75626 (Clean up E0754 explanation)
- #75629 (Use intra-doc links in `std::env`, `std::alloc` and `std::error`)
- #75634 (Mark x86_64-linux-kernel as *)
Failed merges:
r? @ghost
|
|
Allowing raw ptr dereference in const fn
Reflect on issue #75340
Discussion in previous PR #75425
## Updates
Change `UnsafetyViolationKind::General` to `UnsafetyViolationKind::GeneralAndConstFn` in check_unsafety.rs
Remove `unsafe` in min_const_fn_unsafe_bad.rs
Bless min_const_fn
Add the test case from issue 75340
***
Sorry for the chaos. I messed up and ended up deleting the repo in the last PR. I have to create a new PR for the new repo. I will make a feature branch next time. I will edit the old PR once I receive the commends.
@RalfJung Thank you all for your replies. They are helpful!
r? @oli-obk
|
|
rust_ast::ast => rustc_ast
Rework of #71199 which is a rework #70621
Still working on this but just made the PR to track progress
r? @Dylan-DPC
|
|
|
|
|
|
MIR-OPT: Make SimplifyBranchSame able to remove identity match with fieldless variant
Modifies SimplifyBranchSame so that it can see that the statements can be considered equal in the following example
`_0 = _1` and `discriminant(_0) = discriminant(0)` are considered equal if 0 is a fieldless variant of an enum.
|
|
Make `<*const T>::is_null` const fn
r? @RalfJung
cc @rust-lang/wg-const-eval
tracking issue: #74939
|
|
This commit modifies polymorphization's handling of predicates so that
if any generic parameter is used in a predicate then all parameters in
that predicate are used.
Signed-off-by: David Wood <david@davidtw.co>
|
|
miri engine: add option to use force_int for alignment check
This is needed for https://github.com/rust-lang/miri/issues/1074. The Miri-side patch is at https://github.com/rust-lang/miri/pull/1513.
r? @oli-obk
|
|
Co-authored-by: Oliver Scherer <github35764891676564198441@oli-obk.de>
|
|
Change `UnsafetyViolationKind::General` to `UnsafetyViolationKind::GeneralAndConstFn` in check_unsafety.rs
Remove unsafe in min_const_fn_unsafe_bad.rs
Bless min_const_fn
Add the test case from issue 75340
Co-authored-by: lzutao <taolzu@gmail.com>
|
|
and `discriminant(_0) = discriminant(0)` are considered equal if 0 is a fieldless variant of an enum
|
|
|
|
|
|
MatchBranchSimplification: fix equal const bool assignments
The match branch simplification is applied when target blocks contain
statements that are either equal or perform a const bool assignment with
different values to the same place.
Previously, when constructing new statements, only statements from a
single block had been examined. This lead to a misoptimization when
statements are equal because the assign the *same* const bool value to
the same place.
Fix the issue by examining statements from both blocks when deciding on
replacement.
Additionally:
* Copy discriminant instead of moving it since it might be necessary to use its
value more than once.
* Optimize when switching on copy operand
Based on #75508.
r? @oli-obk / @JulianKnodt
|
|
davidtwco:issue-75326-polymorphization-symbol-mangling-v0-predicates, r=lcnr
polymorphize: `I` used if `T` used in `I: Foo<T>`
Fixes #75326.
This PR adjusts polymorphization's handling of predicates so that after ensuring that `T` is used in `I: Foo<T>` if `I` is used, it now ensures that `I` is used if `T` is used in `I: Foo<T>`. This is necessary to mark generic parameters that only exist in impl parameters as used - thereby avoiding symbol clashes when using the new mangling scheme.
With this PR, rustc will now fully bootstrap with polymorphization and the new symbol mangling scheme enabled - not all tests pass, but I'm not sure how much of that is the interaction of the two features, I'll be looking into that soon. All tests pass with only polymorphization enabled.
r? @lcnr (this isn't sufficiently complex that I need to add to eddy's review queue)
cc @eddyb
|
|
merge `as_local_hir_id` with `local_def_id_to_hir_id`
`as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing.
Don't really care about which of these 2 methods we want to keep.
Does this require an MCP, considering that these methods are fairly frequently used?
|
|
|
