The error and check for this already existed, but the parser didn't try to parse trait method arguments as patterns, so the error was never emitted. This surfaces the error, so we get better errors than simple parse errors.
optimize redundant borrows and escaping paths in NLL
This builds on https://github.com/rust-lang/rust/pull/53168 and adds a commit that addresses https://github.com/rust-lang/rust/issues/53176 -- or at least I think it does. I marked this as WIP because I want to see the test results (and measure the performance). I also want to double check we're not adding in any unsoundness here.
Add help message for missing `IndexMut` impl
Code:
```rust
let mut map = HashMap::new();
map.insert("peter", 23);
map["peter"] = 27;
```
Before:
```
error[E0594]: cannot assign to immutable indexed content
--> src/main.rs:7:5
|
7 | map["peter"] = 27;
| ^^^^^^^^^^^^^^^^^ cannot borrow as mutable
```
With this change (just the `help` was added):
```
error[E0594]: cannot assign to immutable indexed content
--> index-error.rs:7:5
|
7 | map["peter"] = 27;
| ^^^^^^^^^^^^^^^^^ cannot borrow as mutable
|
= help: trait `IndexMut` is required to modify indexed content, but it is not implemented for std::collections::HashMap<&str, i32>
```
---
Yesterday I did some pair programming with a Rust-beginner. We created a type and implemented `Index` for it. Trying to modify the value returned by the index operation returns in a rather vague error that was not very clear for the Rust beginner. So I tried to improve the situation.
## Notes/questions for reviewers:
- Is the formulation OK like that? I'm fine with changing it.
- Can we be absolutely sure that `IndexMut` is actually not implemented in the case my `help` message is added? I'm fairly sure myself, but there could be some cases I didn't think of. Also, I don't know the compiler very well, so I don't know what exactly certain enum variants are used for.
- It would be nice to test if `IndexMut` is in fact not implemented for the type, but I couldn't figure out how to check that. If you think that additional check would be beneficial, could you tell me how to check if a trait is implemented?
- Do you think I should change the error message instead of only adding an additional help message?
Rollup of 15 pull requests
Successful merges:
- #52773 (Avoid unnecessary pattern matching against Option and Result)
- #53082 (Fix doc link (again))
- #53094 (Automatically expand section if url id point to one of its component)
- #53106 (atomic ordering docs)
- #53110 (Account for --remap-path-prefix in save-analysis)
- #53116 (NetBSD: fix signedess of char)
- #53179 (Whitelist wasm32 simd128 target feature)
- #53183 (Suggest comma when missing in macro call)
- #53207 (Add individual docs for rotate_{left, right})
- #53211 ([nll] enable feature(nll) on various crates for bootstrap)
- #53214 ([nll] enable feature(nll) on various crates for bootstrap: part 2)
- #53215 (Slightly refactor syntax_ext/format)
- #53217 (inline some short functions)
- #53219 ([nll] enable feature(nll) on various crates for bootstrap: part 3)
- #53222 (A few cleanups for rustc_target)
Suggest comma when missing in macro call
When missing a comma in a macro call, suggest it, regardless of
position. When a macro call doesn't match any of the patterns, check
if the call's token stream could be missing a comma between two idents,
and if so, create a new token stream containing the comma and try to
match against the macro patterns. If successful, emit the suggestion.
This works on arbitrary macros, with no need of special support from
the macro writers.
```
error: no rules expected the token `d`
--> $DIR/missing-comma.rs:26:18
|
LL | foo!(a, b, c d, e);
| -^
| |
| help: missing comma here
```
Follow up to #52397.
Apply some fixes to cross-language LTO (especially when targeting MSVC)
This PR contains a few fixes that were needed in order to get Firefox compiling with Rust/C++ cross-language ThinLTO on Windows. The commits are self-contained and should be self-explanatory.
r? @alexcrichton
[NLL] Use span of the closure args in free region errors
Also adds a note when one of the free regions is BrEnv.
In a future PR I'll change these messages to say "return requires", which should improve them a bit more.
r? @nikomatsakis
resolve: Support custom attributes when macro modularization is enabled
Basically, if resolution of a single-segment attribute is a determined error, then we interpret it as a custom attribute.
Since custom attributes are integrated into general macro resolution, `feature(custom_attribute)` now requires and implicitly enables macro modularization (`feature(use_extern_macros)`).
Actually, a few other "advanced" macro features now implicitly enable macro modularization too (and one bug was found and fixed in process of enabling it).
The first two commits are preliminary cleanups/refactorings.
When missing a comma in a macro call, suggest it, regardless of
position. When a macro call doesn't match any of the patterns, check
if the call's token stream could be missing a comma between two idents,
and if so, create a new token stream containing the comma and try to
match against the macro patterns. If successful, emit the suggestion.
rustc: Tweak visibility of some lang items
This commit tweaks the linker-level visibility of some lang items that rustc
uses and defines. Notably this means that `#[panic_implementation]` and
`#[alloc_error_handler]` functions are never marked as `internal`. It's up to
the linker to eliminate these, not rustc.
Additionally `#[global_allocator]` generated symbols are no longer forced to
`Default` visibility (fully exported), but rather they're relaxed to `Hidden`
visibility). This symbols are *not* needed across DLL boundaries, only as a
local implementation detail of the compiler-injected allocator symbols, so
`Hidden` should suffice.
Closes#51342Closes#52795
revert #52991
Reverts https://github.com/rust-lang/rust/pull/52991 which is flawed. I have an idea how to fix it but might as well revert first since it is so wildly flawed. That's what I get for opening PRs while on PTO =)
r? @pnkfelix
This commit tweaks the linker-level visibility of some lang items that rustc
uses and defines. Notably this means that `#[panic_implementation]` and
`#[alloc_error_handler]` functions are never marked as `internal`. It's up to
the linker to eliminate these, not rustc.
Additionally `#[global_allocator]` generated symbols are no longer forced to
`Default` visibility (fully exported), but rather they're relaxed to `Hidden`
visibility). This symbols are *not* needed across DLL boundaries, only as a
local implementation detail of the compiler-injected allocator symbols, so
`Hidden` should suffice.
Closes#51342Closes#52795
