Instead of lowering them to `<expr> = <expr>`, then hacking on-demand to resolve them, we lower them to `<pat> = <expr>`, and use the pattern infrastructure to handle them. It turns out, destructuring assignments are surprisingly similar to pattern bindings, and so only minor modifications are needed.
This fixes few bugs that arose because of the non-uniform handling (for example, MIR lowering not handling slice and record patterns, and closure capture calculation not handling destructuring assignments at all), and furthermore, guarantees we won't have such bugs in the future, since the programmer will always have to explicitly handle `Expr::Assignment`.
Tests don't pass yet; that's because the generated patterns do not exist in the source map. The next commit will fix that.
Because our lint infra *can* handle allows from within macro expansions!
(Also, what did this reason have to do with something that is a hard error and not a lint? I'm puzzled).
I wonder how many such diagnostics we have...
Maybe that also mean we can change `unused_mut` to no-longer-experimental? But this is a change I'm afraid to do without checking.
feat: initial support for safe_kw in extern blocks
This PR adds initial support for `safe` keywords in external blocks.
## Changes
1. Parsing static declarations with `safe` kw and `unsafe` kw, as well as functions with `safe` kw in extern_blocks
2. Add `HAS_SAFE_KW ` to `FnFlags`
3. Handle `safe` kw in `is_fn_unsafe_to_call` query
4. Handle safe_kw in unsafe diagnostics
internal: Fix editorconfig glob
Had been testing Zed's editorconfig branch on r-a and noticed that something was odd with yaml files.
https://spec.editorconfig.org/#glob-expressions
> {s1,s2,s3}
> any of the strings given (separated by commas, can be nested) (But {s1} only matches {s1} literally.)
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Technically it should be a warning, not an error but warning is not shown by default so keep
it at error I guess.
Fixes#18240
internal: fix lldb-dap unconditionally calling rustc
Fixes https://github.com/rust-lang/rust-analyzer/issues/18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.
I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
Clamp Position::character to line length
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Not sure how to update Cargo.lock (lib/README.md doesn't say how).
Fixes#18240
internal: Use local time when formatting logs
When debugging rust-analyzer and looking at logs, it's much easier to read when the timestamp is in the local timezone.
Before:
2024-08-28T20:55:38.792321Z INFO ParseQuery: invoked at R18460
After:
2024-08-28T13:55:38.792321-07:00 INFO ParseQuery: invoked at R18460
When debugging rust-analyzer and looking at logs, it's much easier to read
when the timestamp is in the local timezone.
Before:
2024-08-28T20:55:38.792321Z INFO ParseQuery: invoked at R18460
After:
2024-08-28T13:55:38.792321-07:00 INFO ParseQuery: invoked at R18460
Fix needless_lifetimes in stable_mir
Hi,
This PR fixes the following clippy warning
```
warning: the following explicit lifetimes could be elided: 'a
--> compiler/stable_mir/src/mir/visit.rs:490:6
|
490 | impl<'a> PlaceRef<'a> {
| ^^ ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
= note: `#[warn(clippy::needless_lifetimes)]` on by default
help: elide the lifetimes
|
490 - impl<'a> PlaceRef<'a> {
490 + impl PlaceRef<'_> {
|
```
Best regards,
Michal
Fix trivially_copy_pass_by_ref in stable_mir
Hi,
This PR fixes the following clippy warnings
```
warning: this argument (8 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
--> compiler/stable_mir/src/mir/body.rs:1042:34
|
1042 | fn subslice_ty(ty: Ty, from: &u64, to: &u64, from_end: &bool) -> Result<Ty, Error> {
| ^^^^ help: consider passing by value instead: `u64`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#trivially_copy_pass_by_ref
= note: requested on the command line with `-W clippy::trivially-copy-pass-by-ref`
warning: this argument (8 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
--> compiler/stable_mir/src/mir/body.rs:1042:44
|
1042 | fn subslice_ty(ty: Ty, from: &u64, to: &u64, from_end: &bool) -> Result<Ty, Error> {
| ^^^^ help: consider passing by value instead: `u64`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#trivially_copy_pass_by_ref
warning: this argument (1 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
--> compiler/stable_mir/src/mir/body.rs:1042:60
|
1042 | fn subslice_ty(ty: Ty, from: &u64, to: &u64, from_end: &bool) -> Result<Ty, Error> {
| ^^^^^ help: consider passing by value instead: `bool`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#trivially_copy_pass_by_ref
```
Best regards,
Michal
Emscripten: Xfail backtrace ui tests
It is possible to link libunwind and use the normal backtrace code, but it fails to symbolize stack traces. I investigated and could get the list of instruction pointers and symbol names, but I'm not sure how to use the dwarf info to map from instruction pointer to source location. In any case, fixing this is not a high priority.
See https://github.com/rust-lang/rust/issues/131738
r?jieyouxu
Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe
We need to structurally resolve the lhs and rhs of the coercion. Also, renaming the method so it's less ambiguous about what it's doing... the word "may" gives more clear signal that it has false positives imo.
r? lcnr
Refactor some `core::fmt` macros
While looking at the macros in `core::fmt`, find that the macros are not well organized. So I created a patch to fix it.
[`core/src/fmt/num.rs`](https://github.com/rust-lang/rust/blob/master/library/core/src/fmt/num.rs)
* `impl_int!` and `impl_uint!` macro are **completly** same. It would be better to combine for readability
* `impl_int!` has a problem that the indenting is not uniform. It has unified into 4 spaces
* `debug` macro in `num` renamed to `impl_Debug`, And it was moved to a position close to the `impl_Display`.
[`core/src/fmt/float.rs`](https://github.com/rust-lang/rust/blob/master/library/core/src/fmt/float.rs)
[`core/src/fmt/nofloat.rs`](https://github.com/rust-lang/rust/blob/master/library/core/src/fmt/nofloat.rs)
* `floating` macro now receive multiple idents at once. It makes the code cleaner.
* Modified the panic message more clearly in fallback function of `cfg(no_fp_fmt_parse)`
Delay ambiguous intra-doc link resolution after `Cache` has been populated
Fixes https://github.com/rust-lang/rust/issues/130233.
I was getting nowhere with #130278. I took a wrong turn at some point and ended making way too many changes so instead I started again back from 0 and this time it worked out as expected.
r? ```@notriddle```
Rustfmt `for<'a> async` correctly
In #127054, we decided to move the trait bound modifier for `async for<'a> Fn()` to `for<'a> async Fn()`. This wasn't adjusted in rustfmt, so this PR implements that. It also requires consolidating the bound formatting into the `Rewrite` impl for `PolyTraitRef`.
Fixes#131649
Don't check unsize goal in MIR validation when opaques remain
Similarly to `mir_assign_valid_types`, let's just skip when there are opaques. Fixes#130921.
Fix explicit_iter_loop in rustc_serialize
Hi,
This PR fixes some clippy warnings
```
warning: it is more concise to loop over references to containers instead of using explicit iteration methods
--> compiler/rustc_serialize/src/serialize.rs:675:18
|
675 | for e in self.iter() {
| ^^^^^^^^^^^ help: to write this more concisely, try: `self`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#explicit_iter_loop
```
Best regards,
Michal
Ignore lint-non-snake-case-crate#proc_macro_ on targets without unwind
The lint-non-snake-case-crate test may emit a warning in stderr if the target does not support unwinding
```
warning: building proc macro crate with `panic=abort` may crash the compiler should the proc-macro panic
```
Consequently, the test will fail on targets that don't support unwinding as written.
This change modifies the expected stderr for lint-non-snake-case-crate in the proc_macro_ to ignore lines that indicate a warning was emitted.
Try to improve error messages involving aliases in the solver
1. Treat aliases as rigid only if it may not be defined and it's well formed (i.e. for projections, its trait goal is satisfied).
2. Record goals that are related to alias normalization under a new `GoalKind`, so we can look into them in the `BestObligation` visitor.
3. Try to deduplicate errors due to self types of goals that are un-normalizable aliases.
r? lcnr
Add fast-path when computing the default visibility
This PR adds (or more correctly re-adds the) fast-path when computing the default visibility, by taking advantage of the fact that the "interposable" requested visibility always return the "default" codegen visibility.
Should address the small regression observed in https://github.com/rust-lang/rust/pull/131111#issuecomment-2402273967.
r? `@lqd`
