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.
`BindingAnnotation` refactor
* `ast::BindingMode` is deleted and replaced with `hir::BindingAnnotation` (which is moved to `ast`)
* `BindingAnnotation` is changed from an enum to a tuple struct e.g. `BindingAnnotation(ByRef::No, Mutability::Mut)`
* Associated constants added for convenience `BindingAnnotation::{NONE, REF, MUT, REF_MUT}`
One goal is to make it more clear that `BindingAnnotation` merely represents syntax `ref mut` and not the actual binding mode. This was especially confusing since we had `ast::BindingMode`->`hir::BindingAnnotation`->`thir::BindingMode`.
I wish there were more symmetry between `ByRef` and `Mutability` (variant) naming (maybe `Mutable::Yes`?), and I also don't love how long the name `BindingAnnotation` is, but this seems like the best compromise. Ideas welcome.
Don't duplicate file descriptors into stdio fds
Ensures that file descriptors are never duplicated into the stdio fds even if a stdio fd has been closed.
Revert "Mention rust-analyzer maintainers when `proc_macro` bridge is changed"
Reverts rust-lang/rust#99183
rust-analyzer is now a subtree, and CI fails when the `proc_macro` bridge changes break our tests, so these notifications aren't needed anymore.
Add a Machine hook for inline assembly
I'm sketching out some support in Miri to "execute" inline assembly. I want this because there are codebases which have very simple inline assembly like hand-written syscall wrappers, and it would be nice to test such code without modification.
r? ``@oli-obk``
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`
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
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)
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`
Suggested by the team in this Zulip Topic https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20SessionDiagnostic.20on.20Handler
Handler already has almost all the capabilities of ParseSess when it comes to diagnostic emission, in this migration we only needed to add the ability to access source_map from the emitter in order to get a Snippet and the start_point. Not sure if this is the best way to address this gap
