| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 5 pull requests
Successful merges:
- #100658 (TyCtxt::get_attr should check that no duplicates are allowed)
- #101021 (Migrate ``rustc_middle`` diagnostic)
- #101287 (Document eager evaluation of `bool::then_some` argument)
- #101412 (Some more cleanup in `core`)
- #101427 (Fix ICE, generalize 'move generics to trait' suggestion for >0 non-rcvr arguments)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix ICE, generalize 'move generics to trait' suggestion for >0 non-rcvr arguments
Fixes #101421
cc #100838
|
|
TyCtxt::get_attr should check that no duplicates are allowed
Fixes #100631
|
|
Suggest removing unnecessary prefix let in patterns
Helps with #101291, though I think `@estebank` probably wants this:
> Finally, I think it'd be nice if we could detect that we don't know for sure and "just" swallow the rest of the expression (find the next ; accounting for nested braces) or the end of the item (easier).
... to be implemented before we close that issue out completely.
|
|
|
|
compiler-errors:cannot-call-trait-object-with-unsized-return, r=lcnr
Point out when a callable is not actually callable because its return is not sized
Fixes #100755
I didn't add a UI test for that one because it's equivalent to the UI test that already exists in the suite.
|
|
Point at type parameter in plain path expr
Slightly better error message for a kinda unique use case.
|
|
Add let else drop order tests
Add a systematic matrix based test that checks temporary drop order in various settings, `let-else-drop-order.rs`, as requested [here](https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523).
The drop order of let and let else is supposed to be the and in order to ensure this, the test checks that this holds for a number of cases.
The test also ensures that we drop the temporaries of the condition before executing the else block.
cc #87335 tracking issue for `let else`
|
|
sized
|
|
arguments
|
|
fix `ExprKind` static_assert_size
fix hir-stats
|
|
The drop order of let and let else is supposed to be the same,
and in order to ensure this, the test checks that this holds for
the given list of cases.
The test also ensures that we drop the temporaries of the
condition before executing the else block.
We made the test matrix based so it can check all the possible
combinations and find out possible edge cases.
|
|
Rollup of 6 pull requests
Successful merges:
- #101142 (Improve HIR stats)
- #101367 (Suggest `{Option,Result}::{copied,clone}()` to satisfy type mismatch)
- #101391 (more clippy::perf fixes)
- #101409 (Don't fire `rust_2021_incompatible_closure_captures` in `edition = 2021` crates)
- #101420 (Fix `hir::Local` doc to match with the variable name used: `init`)
- #101429 (Don't suggest reborrow if usage is inside a closure)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't suggest reborrow if usage is inside a closure
I can't think of why we would ever be able to *successfully* suggest a mutable reborrow `&mut *` due to a move happening due to a closure, so just suppress it.
Fixes #101119
|
|
WaffleLapkin:rust_2021_compatibility_no_warn_in_2021_crates, r=TaKO8Ki
Don't fire `rust_2021_incompatible_closure_captures` in `edition = 2021` crates
Fixes #101284
|
|
Suggest `{Option,Result}::{copied,clone}()` to satisfy type mismatch
Fixes #100699, but in the opposite direction (instead of suggesting to fix the signature, it fixes the body)
|
|
Improve HIR stats
#100398 improve the AST stats collection done by `-Zhir-stats`. This PR does the same for HIR stats collection.
r? `@davidtwco`
|
|
proc_macro/bridge: use the cross-thread executor for nested proc-macros
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with `@eddyb,` we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? `@eddyb`
|
|
|
|
r=oli-obk,RalfJung
Make `const_eval_select` a real intrinsic
This fixes issues where `track_caller` functions do not have nice panic
messages anymore when there is a call to the function, and uses the
MIR system to replace the call instead of dispatching via lang items.
Fixes #100696.
|
|
|
|
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with @eddyb, we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? @eddyb
|
|
Don't delay invalid LHS bug unless it will be covered by an error in `check_overloaded_binop`
Fixes #101376
|
|
|
|
Use head span for `rustc_on_unimplemented`'s `enclosing_scope` attr
This may make #101281 slightly easier to understand
|
|
|
|
safe transmute: use `Assume` struct to provide analysis options
This task was left as a TODO in #92268; resolving it brings [`BikeshedIntrinsicFrom`](https://doc.rust-lang.org/nightly/core/mem/trait.BikeshedIntrinsicFrom.html) more in line with the API defined in [MCP411](https://github.com/rust-lang/compiler-team/issues/411).
**Before:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<
Src,
Context,
const ASSUME_ALIGNMENT: bool,
const ASSUME_LIFETIMES: bool,
const ASSUME_VALIDITY: bool,
const ASSUME_VISIBILITY: bool,
> where
Src: ?Sized,
{}
```
**After:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<Src, Context, const ASSUME: Assume = { Assume::NOTHING }>
where
Src: ?Sized,
{}
```
`Assume::visibility` has also been renamed to `Assume::safety`, as library safety invariants are what's actually being assumed; visibility is just the mechanism by which it is currently checked (and that may change).
r? `@oli-obk`
---
Related:
- https://github.com/rust-lang/compiler-team/issues/411
- https://github.com/rust-lang/rust/issues/99571
|
|
|
|
|
|
|
|
Fix `global_asm` macro pretty printing
Fixes #101051
Fixes #101047
|
|
Make trait bound not satisfied specify kind
Closes #99875
|
|
Suggest associated method on deref types when path syntax method fails
Fixes #100278
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #101335 (rustdoc: remove old CSS selector that causes weird spacing)
- #101347 (ffx component run should provide a collection)
- #101364 (Shrink suggestion span of argument mismatch error)
- #101365 (remove redundant clones)
Failed merges:
- #101349 (rustdoc: remove `.impl-items { flex-basis }` CSS, not in flex container)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Shrink suggestion span of argument mismatch error
This doesn't really help with #101242, but I wanted to put this up while I work on other fixes.
|
|
Add warning against unexpected --cfg with --check-cfg
This PR adds a warning when an unexpected `--cfg` is specified but not in the specified list of `--check-cfg`.
This is the follow-up PR I mentioned in https://github.com/rust-lang/rust/pull/99519.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
|
|
|
|
[drop tracking] Use parent expression for scope, not parent node
Previously we were just using the parent node as the scope for a temporary value, but it turns out this is too narrow. For example, in an expression like
Foo {
b: &42,
a: async { 0 }.await,
}
the scope for the &42 was set to the ExprField node for `b: &42`, when we actually want to use the Foo struct expression.
We fix this by recursively searching through parent nodes until we find a Node::Expr. It may be that we don't find one, and if so that's okay, we will just fall back on the enclosing temporary scope which is always sufficient.
Helps with #97331
r? ``@jyn514``
|
|
r=pnkfelix
Revert "Remove deferred sized checks"
cc: https://github.com/rust-lang/rust/pull/100652#issuecomment-1225798572
I'm okay with reverting this for now, and I will look into the diagnostic regressions.
This reverts commit 33212bf7f527798a8cfa2bbb38781742f4ca718a.
r? `@pnkfelix`
----
EDIT: This _also_ fixes #101066, a regression in method selection logic/coercion(?) due to the early registering of a `Sized` bound.
|
|
Support `#[unix_sigpipe = "inherit|sig_dfl"]` on `fn main()` to prevent ignoring `SIGPIPE`
When enabled, programs don't have to explicitly handle `ErrorKind::BrokenPipe` any longer. Currently, the program
```rust
fn main() { loop { println!("hello world"); } }
```
will print an error if used with a short-lived pipe, e.g.
% ./main | head -n 1
hello world
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', library/std/src/io/stdio.rs:1016:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
by enabling `#[unix_sigpipe = "sig_dfl"]` like this
```rust
#![feature(unix_sigpipe)]
#[unix_sigpipe = "sig_dfl"]
fn main() { loop { println!("hello world"); } }
```
there is no error, because `SIGPIPE` will not be ignored and thus the program will be killed appropriately:
% ./main | head -n 1
hello world
The current libstd behaviour of ignoring `SIGPIPE` before `fn main()` can be explicitly requested by using `#[unix_sigpipe = "sig_ign"]`.
With `#[unix_sigpipe = "inherit"]`, no change at all is made to `SIGPIPE`, which typically means the behaviour will be the same as `#[unix_sigpipe = "sig_dfl"]`.
See https://github.com/rust-lang/rust/issues/62569 and referenced issues for discussions regarding the `SIGPIPE` problem itself
See the [this](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem) Zulip topic for more discussions, including about this PR.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
|
|
Try normalizing types without RevealAll in ParamEnv in MIR validation
Before, the MIR validator used RevealAll in its ParamEnv for type
checking. This could cause false negatives in some cases due to
RevealAll ParamEnvs not always use all predicates as expected here.
Since some MIR passes like inlining use RevealAll as well, keep using
it in the MIR validator too, but when it fails usign RevealAll, also
try the check without it, to stop false negatives.
Fixes #99866
cc ````````@compiler-errors```````` who nicely helped me on zulip
|
|
|
|
optimization of access level table construction
Refactoring which was mentioned in #87487
|
|
Uplift the `let_underscore` lints from clippy into rustc.
This PR resolves #97241.
This PR adds three lints from clippy--`let_underscore_drop`, `let_underscore_lock`, and `let_underscore_must_use`, which are meant to capture likely-incorrect uses of `let _ = ...` bindings (in particular, doing this on a type with a non-trivial `Drop` causes the `Drop` to occur immediately, instead of at the end of the scope. For a type like `MutexGuard`, this effectively releases the lock immediately, which is almost certainly the wrong behavior)
In porting the lints from clippy I had to copy over a bunch of utility functions from `clippy_util` that these lints also relied upon. Is that the right approach?
Note that I've set the `must_use` and `drop` lints to Allow by default and set `lock` to Deny by default (this matches the same settings that clippy has). In talking with `@estebank` he informed me to do a Crater run (I am not sure what type of Crater run to request here--I think it's just "check only"?)
On the linked issue, there's some discussion about using `must_use` and `Drop` together as a heuristic for when to warn--I did not implement this yet.
r? `@estebank`
|
|
TaKO8Ki:do-not-suggest-adding-move-when-closure-is-already-marked-as-move, r=oli-obk
Do not suggest adding `move` to closure when `move` is already used
Fixes #101227
|
