- If an existential type is defined, but no user code infers the
concrete type behind the existential type, normalization would
infinitely recurse on this existential type which is only defined in
terms of itself.
- Instead of raising an inf recurse error, we cause a cycle error to
help highlight that the issue is that the type is only defined in terms
of itself.
- Three known potential improvements:
- If type folding itself was exposed as a query, used by
normalization and other mechanisms, cases that would cause infinite recursion would
automatically cause a cycle error.
- The span for the cycle error should be improved to point to user
code that fails to allow inference of the concrete type of the existential type,
assuming that this error occurs because no user code can allow inference the
concrete type.
- A mechanism to extend the cycle error with a helpful note would be nice. Currently,
the error is built and maintained by src/librustc/ty/query/plumbing,
with no known way to extend the information that the error gets built
with.
Fix a few regressions from enabling macro modularization
The first commit restores the old behavior for some minor unstable stuff (`rustc_*` and `derive_*` attributes) and adds a new feature gate for arbitrary tokens in non-macro attributes.
The second commit fixes https://github.com/rust-lang/rust/issues/53205
The third commit fixes https://github.com/rust-lang/rust/issues/53144.
Same technique is used as for other things blocking expansion progress - if something causes indeterminacy too often, then prohibit it.
In this case referring to crate-local macro-expanded `#[macro_export]` macros via module-relative paths is prohibited, see comments in code for more details.
cc https://github.com/rust-lang/rust/pull/50911
Emit error for pattern arguments in trait methods
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.
This improves the error message described in https://github.com/rust-lang/rust/issues/53046.
r? @petrochenkov
wherein we suggest float for integer literals where a float was expected
@sunjay pointed out that this is a nice thing that we could do.
Resolves#53280.
r? @estebank
Update compiler test documentation
Update the compiler test documentation to document ignore-gdb-version
and min-system-llvm-version; and expand the min-gdb-version,
min-lldb-version, and min-llvm-version documentation a little.
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
Place unions, pointer casts and pointer derefs behind extra feature gates
To ensure we don't stabilize these things together with const fn stabilization (or any other stabilization)
This PR moves union field accesses inside `const fn` behind a feature gate. It was possible without a feature gate before, but since `const fn` was behind a feature gate we can do this change.
While "dereferencing raw pointers" and "casting raw pointers to usize" were hard errors before this PR, one could work around them by abusing unions:
```rust
// deref
union Foo<T> {
x: &'static T,
y: *const T,
}
const FOO: u32 = unsafe { *Foo { y: 42 as *const T }.x };
// as usize cast
union Bar<T> {
x: usize,
y: *const T,
}
const BAR: usize = unsafe { Bar { y: &1u8 }.x };
```
r? @eddyb
cc @nikomatsakis
