| Age | Commit message (Collapse) | Author | Lines |
|
Fixes #46213
|
|
This is in anticipation of a new enum layout, in which the niche
optimization may be applied even when multiple variants have data.
|
|
TaKO8Ki:do-not-suggest-semicolon-for-macro-without-exclamation-mark, r=wesleywiser
Do not suggest a semicolon for a macro without `!`
Fixes a regression in #101490
|
|
Debuginfo line information for macro invocations are collapsed by
default - line information are replaced by the line of the outermost
expansion site. Using `-Zdebug-macros` disables this behaviour.
When the `collapse_debuginfo` feature is enabled, the default behaviour
is reversed so that debuginfo is not collapsed by default. In addition,
the `#[collapse_debuginfo]` attribute is available and can be applied to
macro definitions which will then have their line information collapsed.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Add list of recognized repr attributes to the unrecognized repr error
|
|
fix RPIT ICE for implicit HRTB when missing dyn
Closes #101297
r? `@cjgillot`
cc `@nikomatsakis`
|
|
|
|
|
|
|
|
|
|
Recover from using `;` as separator between fields
Partially fixes #101440 (only for record structs).
Doing that for tuple structs is harder as their parsing passes through a bunch of helper functions. I don't know how to do that. But [their error message is better anyway](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cc6ee8bb2593596c0cea89d49e79bcb4) and suggests using a comma, even if it doesn't suggest replacing the semicolon with it.
|
|
r=oli-obk
Suggest introducing an explicit lifetime if it does not exist
Fixes #101027
|
|
Include enum path in variant suggestion
(except for `Result` and `Option`, which we should have via the prelude)
Fixes #101356
|
|
|
|
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
|