| Age | Commit message (Collapse) | Author | Lines |
|---|
|
resolve: Implement prelude search for macro paths, implement tool attributes
When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.
"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.
The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).
Fixes https://github.com/rust-lang/rust/issues/52576
Fixes https://github.com/rust-lang/rust/issues/52512
Fixes https://github.com/rust-lang/rust/issues/51277
cc https://github.com/rust-lang/rust/issues/52269
|
|
[NLL] Dangly paths for box
Special-case `Box` in `rustc_mir::borrow_check`.
Since we know dropping a box will not access any `&mut` or `&` references, it is safe to model its destructor as only touching the contents *owned* by the box.
----
There are three main things going on here:
1. The first main thing, this PR is fixing a bug in NLL where `rustc` previously would issue a diagnostic error in a case like this:
```rust
fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
```
such code was accepted by the AST-borrowck in the past, but NLL was rejecting it with the following message ([playground](https://play.rust-lang.org/?gist=13c5560f73bfb16d6dab3ceaad44c0f8&version=nightly&mode=release&edition=2015))
```
error[E0597]: `**x` does not live long enough
--> src/main.rs:3:40
|
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
| ^^^^^^^^ - `**x` dropped here while still borrowed
| |
| borrowed value does not live long enough
|
note: borrowed value must be valid for the anonymous lifetime #1 defined on the function body at 3:1...
--> src/main.rs:3:1
|
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
2. The second main thing: The reason such code was previously rejected was because NLL (MIR-borrowck) incorporates a fix for issue #31567, where it models a destructor's execution as potentially accessing any borrows held by the thing being destructed. The tests with `Scribble` model this, showing that the compiler now catches such unsoundness.
However, that fix for issue #31567 is too strong, in that NLL (MIR-borrowck) includes `Box` as one of the types with a destructor that potentially accesses any borrows held by the box. This thus was the cause of the main remaining discrepancy between AST-borrowck and MIR-borrowck, as documented in issue #45696, specifically in [the last example of this comment](https://github.com/rust-lang/rust/issues/45696#issuecomment-345367873), which I have adapted into the `fn foo` shown above.
We did close issue #45696 back in December of 2017, but AFAICT that example was not fixed by PR #46268. (And we did not include a test, etc etc.)
This PR fixes that case, by trying to model the so-called `DerefPure` semantics of `Box<T>` when we traverse the type of the input to `visit_terminator_drop`.
3. The third main thing is that during a review of the first draft of this PR, @matthewjasper pointed out that the new traversal of `Box<T>` could cause the compiler to infinite loop. I have adjusted the PR to avoid this (by tracking what types we have previously seen), and added a much needed test of this somewhat odd scenario. (Its an odd scenario because the particular case only arises for things like `struct A(Box<A>);`, something which cannot be constructed in practice.)
Fix #45696.
|
|
Switch to bootstrapping from 1.29 beta
r? @alexcrichton
|
|
pnkfelix:issue-52967-edition-2018-implies-2-phase-borrows, r=Mark-Simulacrum
NLL migration in the 2018 edition needs two-phase borrows too!
NLL migration in the 2018 edition needs two-phase borrows too!
Fix #52967.
|
|
too!
Fix #52967.
|
|
Reexport tests without polluting namespaces
This should fix issue #52557.
Basically now we gensym a new name for the test function and reexport that.
That way the test function's reexport name can't conflict because it was impossible for the test author to write it down.
We then use a `use` statement to expose the original name using the original visibility.
|
|
async can begin expressions
Fix https://github.com/rust-lang/rust/issues/52951
r? @petrochenkov
|
|
rustc_resolve: record single-segment extern crate import resolutions.
Fixes #52489 by recording special-cased single-segment imports for later (e.g. stability) checks.
cc @alexcrichton @Mark-Simulacrum @petrochenkov
Does this need to be backported?
|
|
rustc: Trim down the `rust_2018_idioms` lint group
These migration lints aren't all up to par in terms of a good migration
experience. Some, like `unreachable_pub`, hit bugs like #52665 and unprepared
macros to be handled enough of the time. Others like linting against
`#[macro_use]` are swimming upstream in an ecosystem that's not quite ready (and
slightly buggy pending a few current PRs).
The general idea is that we will continue to recommend the `rust_2018_idioms`
lint group as part of the transition guide (as an optional step) but we'll be
much more selective about which lints make it into this group. Only those with a
strong track record of not causing too much churn will make the cut.
cc #52679
|
|
Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator
This should fix https://github.com/rust-lang/rust/issues/52792.
r? @eddyb
|
|
Use SetLenOnDrop in Vec::truncate()
This avoids a redundant length check in some cases when calling
`Vec::truncate` or `Vec::clear`.
Fixes #51802
Note that the generated code still seems suboptimal. I tested with the following functions:
```rust
#[no_mangle]
pub extern fn foo(x: &mut Vec<u8>) {
x.clear();
}
#[no_mangle]
pub extern fn bar(x: &mut Vec<u8>) {
x.truncate(5);
}
#[no_mangle]
pub extern fn baz(x: &mut Vec<u8>, n: usize) {
x.truncate(n);
}
#[no_mangle]
pub extern fn foo_string(x: &mut Vec<String>) {
x.clear();
}
#[no_mangle]
pub extern fn bar_string(x: &mut Vec<String>) {
x.truncate(5);
}
#[no_mangle]
pub extern fn baz_string(x: &mut Vec<String>, n: usize) {
x.truncate(n);
}
```
<details>
<summary>Old output</summary>
```asm
00000000000460a0 <foo>:
460a0: 48 83 7f 10 00 cmpq $0x0,0x10(%rdi)
460a5: 74 08 je 460af <foo+0xf>
460a7: 48 c7 47 10 00 00 00 movq $0x0,0x10(%rdi)
460ae: 00
460af: c3 retq
00000000000460b0 <bar>:
460b0: 48 83 7f 10 06 cmpq $0x6,0x10(%rdi)
460b5: 72 08 jb 460bf <bar+0xf>
460b7: 48 c7 47 10 05 00 00 movq $0x5,0x10(%rdi)
460be: 00
460bf: c3 retq
00000000000460c0 <baz>:
460c0: 48 39 77 10 cmp %rsi,0x10(%rdi)
460c4: 76 04 jbe 460ca <baz+0xa>
460c6: 48 89 77 10 mov %rsi,0x10(%rdi)
460ca: c3 retq
460cb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
00000000000460d0 <foo_string>:
460d0: 41 57 push %r15
460d2: 41 56 push %r14
460d4: 53 push %rbx
460d5: 48 8b 47 10 mov 0x10(%rdi),%rax
460d9: 48 85 c0 test %rax,%rax
460dc: 74 4a je 46128 <foo_string+0x58>
460de: 49 89 fe mov %rdi,%r14
460e1: 48 8b 0f mov (%rdi),%rcx
460e4: 48 8d 14 40 lea (%rax,%rax,2),%rdx
460e8: 48 8d 58 ff lea -0x1(%rax),%rbx
460ec: 4c 8d 3c d1 lea (%rcx,%rdx,8),%r15
460f0: 49 83 c7 f0 add $0xfffffffffffffff0,%r15
460f4: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
460fb: 00 00 00
460fe: 66 90 xchg %ax,%ax
46100: 49 89 5e 10 mov %rbx,0x10(%r14)
46104: 49 8b 37 mov (%r15),%rsi
46107: 48 85 f6 test %rsi,%rsi
4610a: 74 0e je 4611a <foo_string+0x4a>
4610c: 49 8b 7f f8 mov -0x8(%r15),%rdi
46110: ba 01 00 00 00 mov $0x1,%edx
46115: e8 a6 e9 ff ff callq 44ac0 <__rust_dealloc@plt>
4611a: 48 83 c3 ff add $0xffffffffffffffff,%rbx
4611e: 49 83 c7 e8 add $0xffffffffffffffe8,%r15
46122: 48 83 fb ff cmp $0xffffffffffffffff,%rbx
46126: 75 d8 jne 46100 <foo_string+0x30>
46128: 5b pop %rbx
46129: 41 5e pop %r14
4612b: 41 5f pop %r15
4612d: c3 retq
4612e: 66 90 xchg %ax,%ax
0000000000046130 <bar_string>:
46130: 41 57 push %r15
46132: 41 56 push %r14
46134: 53 push %rbx
46135: 4c 8b 7f 10 mov 0x10(%rdi),%r15
46139: 49 83 ff 06 cmp $0x6,%r15
4613d: 72 49 jb 46188 <bar_string+0x58>
4613f: 49 89 fe mov %rdi,%r14
46142: 48 8b 07 mov (%rdi),%rax
46145: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx
46149: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
4614d: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
46151: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
46158: 00 00 00
4615b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
46160: 49 83 c7 ff add $0xffffffffffffffff,%r15
46164: 4d 89 7e 10 mov %r15,0x10(%r14)
46168: 48 8b 33 mov (%rbx),%rsi
4616b: 48 85 f6 test %rsi,%rsi
4616e: 74 0e je 4617e <bar_string+0x4e>
46170: 48 8b 7b f8 mov -0x8(%rbx),%rdi
46174: ba 01 00 00 00 mov $0x1,%edx
46179: e8 42 e9 ff ff callq 44ac0 <__rust_dealloc@plt>
4617e: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
46182: 49 83 ff 05 cmp $0x5,%r15
46186: 77 d8 ja 46160 <bar_string+0x30>
46188: 5b pop %rbx
46189: 41 5e pop %r14
4618b: 41 5f pop %r15
4618d: c3 retq
4618e: 66 90 xchg %ax,%ax
0000000000046190 <baz_string>:
46190: 41 57 push %r15
46192: 41 56 push %r14
46194: 41 54 push %r12
46196: 53 push %rbx
46197: 50 push %rax
46198: 4c 8b 67 10 mov 0x10(%rdi),%r12
4619c: 49 39 f4 cmp %rsi,%r12
4619f: 76 46 jbe 461e7 <baz_string+0x57>
461a1: 49 89 f6 mov %rsi,%r14
461a4: 49 89 ff mov %rdi,%r15
461a7: 48 8b 07 mov (%rdi),%rax
461aa: 4b 8d 0c 64 lea (%r12,%r12,2),%rcx
461ae: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
461b2: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
461b6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
461bd: 00 00 00
461c0: 49 83 c4 ff add $0xffffffffffffffff,%r12
461c4: 4d 89 67 10 mov %r12,0x10(%r15)
461c8: 48 8b 33 mov (%rbx),%rsi
461cb: 48 85 f6 test %rsi,%rsi
461ce: 74 0e je 461de <baz_string+0x4e>
461d0: 48 8b 7b f8 mov -0x8(%rbx),%rdi
461d4: ba 01 00 00 00 mov $0x1,%edx
461d9: e8 e2 e8 ff ff callq 44ac0 <__rust_dealloc@plt>
461de: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
461e2: 4d 39 f4 cmp %r14,%r12
461e5: 77 d9 ja 461c0 <baz_string+0x30>
461e7: 48 83 c4 08 add $0x8,%rsp
461eb: 5b pop %rbx
461ec: 41 5c pop %r12
461ee: 41 5e pop %r14
461f0: 41 5f pop %r15
461f2: c3 retq
461f3: 90 nop
461f4: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
461fb: 00 00 00
461fe: 66 90 xchg %ax,%ax
```
</details>
<details>
<summary>New output</summary>
```asm
0000000000084d10 <foo>:
84d10: 48 c7 47 10 00 00 00 movq $0x0,0x10(%rdi)
84d17: 00
84d18: c3 retq
84d19: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
0000000000084d20 <bar>:
84d20: 48 8b 47 10 mov 0x10(%rdi),%rax
84d24: 48 83 f8 05 cmp $0x5,%rax
84d28: b9 05 00 00 00 mov $0x5,%ecx
84d2d: 48 0f 42 c8 cmovb %rax,%rcx
84d31: 48 89 4f 10 mov %rcx,0x10(%rdi)
84d35: c3 retq
84d36: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
84d3d: 00 00 00
0000000000084d40 <baz>:
84d40: 48 8b 47 10 mov 0x10(%rdi),%rax
84d44: 48 39 f0 cmp %rsi,%rax
84d47: 48 0f 47 c6 cmova %rsi,%rax
84d4b: 48 89 47 10 mov %rax,0x10(%rdi)
84d4f: c3 retq
0000000000084d50 <foo_string>:
84d50: 41 57 push %r15
84d52: 41 56 push %r14
84d54: 53 push %rbx
84d55: 49 89 fe mov %rdi,%r14
84d58: 4c 8b 7f 10 mov 0x10(%rdi),%r15
84d5c: 4d 85 ff test %r15,%r15
84d5f: 74 2f je 84d90 <foo_string+0x40>
84d61: 49 8b 06 mov (%r14),%rax
84d64: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx
84d68: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
84d6c: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
84d70: 48 8b 33 mov (%rbx),%rsi
84d73: 48 85 f6 test %rsi,%rsi
84d76: 74 0e je 84d86 <foo_string+0x36>
84d78: 48 8b 7b f8 mov -0x8(%rbx),%rdi
84d7c: ba 01 00 00 00 mov $0x1,%edx
84d81: e8 1a b1 ff ff callq 7fea0 <__rust_dealloc@plt>
84d86: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
84d8a: 49 83 c7 ff add $0xffffffffffffffff,%r15
84d8e: 75 e0 jne 84d70 <foo_string+0x20>
84d90: 49 c7 46 10 00 00 00 movq $0x0,0x10(%r14)
84d97: 00
84d98: 5b pop %rbx
84d99: 41 5e pop %r14
84d9b: 41 5f pop %r15
84d9d: c3 retq
84d9e: 66 90 xchg %ax,%ax
0000000000084da0 <bar_string>:
84da0: 41 57 push %r15
84da2: 41 56 push %r14
84da4: 53 push %rbx
84da5: 49 89 fe mov %rdi,%r14
84da8: 4c 8b 7f 10 mov 0x10(%rdi),%r15
84dac: 49 83 ff 06 cmp $0x6,%r15
84db0: 72 44 jb 84df6 <bar_string+0x56>
84db2: 49 8b 06 mov (%r14),%rax
84db5: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx
84db9: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
84dbd: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
84dc1: 49 83 c7 fb add $0xfffffffffffffffb,%r15
84dc5: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
84dcc: 00 00 00
84dcf: 90 nop
84dd0: 48 8b 33 mov (%rbx),%rsi
84dd3: 48 85 f6 test %rsi,%rsi
84dd6: 74 0e je 84de6 <bar_string+0x46>
84dd8: 48 8b 7b f8 mov -0x8(%rbx),%rdi
84ddc: ba 01 00 00 00 mov $0x1,%edx
84de1: e8 ba b0 ff ff callq 7fea0 <__rust_dealloc@plt>
84de6: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
84dea: 49 83 c7 ff add $0xffffffffffffffff,%r15
84dee: 75 e0 jne 84dd0 <bar_string+0x30>
84df0: 41 bf 05 00 00 00 mov $0x5,%r15d
84df6: 4d 89 7e 10 mov %r15,0x10(%r14)
84dfa: 5b pop %rbx
84dfb: 41 5e pop %r14
84dfd: 41 5f pop %r15
84dff: c3 retq
0000000000084e00 <baz_string>:
84e00: 41 57 push %r15
84e02: 41 56 push %r14
84e04: 41 54 push %r12
84e06: 53 push %rbx
84e07: 50 push %rax
84e08: 49 89 ff mov %rdi,%r15
84e0b: 48 8b 47 10 mov 0x10(%rdi),%rax
84e0f: 49 89 c4 mov %rax,%r12
84e12: 49 29 f4 sub %rsi,%r12
84e15: 76 3c jbe 84e53 <baz_string+0x53>
84e17: 49 89 f6 mov %rsi,%r14
84e1a: 49 8b 0f mov (%r15),%rcx
84e1d: 48 8d 04 40 lea (%rax,%rax,2),%rax
84e21: 48 8d 1c c1 lea (%rcx,%rax,8),%rbx
84e25: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
84e29: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
84e30: 48 8b 33 mov (%rbx),%rsi
84e33: 48 85 f6 test %rsi,%rsi
84e36: 74 0e je 84e46 <baz_string+0x46>
84e38: 48 8b 7b f8 mov -0x8(%rbx),%rdi
84e3c: ba 01 00 00 00 mov $0x1,%edx
84e41: e8 5a b0 ff ff callq 7fea0 <__rust_dealloc@plt>
84e46: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
84e4a: 49 83 c4 ff add $0xffffffffffffffff,%r12
84e4e: 75 e0 jne 84e30 <baz_string+0x30>
84e50: 4c 89 f0 mov %r14,%rax
84e53: 49 89 47 10 mov %rax,0x10(%r15)
84e57: 48 83 c4 08 add $0x8,%rsp
84e5b: 5b pop %rbx
84e5c: 41 5c pop %r12
84e5e: 41 5e pop %r14
84e60: 41 5f pop %r15
84e62: c3 retq
84e63: 90 nop
84e64: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
84e6b: 00 00 00
84e6e: 66 90 xchg %ax,%ax
```
</details>
For calling `truncate` with non-zero lengths on non-`Drop` types, it seems that a redundant load and comparison gets replaced with an awkward sequence with a conditional move. In the unknown length case, the new code is no longer awkward.
Maybe someone moderately proficient at assembly could tell if this looks like a win or not.
---
This came up when discussing replacing `unsafe { vec.set_len(0) }` with `vec.clear()` in a project where the author was worried about potential performance degradation. It might be worth replacing some unsafe code, even it it's trivial to see that it's actually safe.
|
|
tests/ui: Add missing mips{64} ignores
|
|
Fix Alias intra doc ICE
Fixes #52611.
cc @QuietMisdreavus
r? @varkor
|
|
[NLL] Allow conflicting borrows of promoted length zero arrays
This is currently overkill as there's no way to create two conflicting borrows of any promoted.
It is possible that the following code might not fail due to const eval in the future (@oli-obk?). In which case either the array marked needs to not be promoted, or to be checked for conflicts
```rust
static mut A: () = {
let mut y = None;
let z;
let mut done_y = false;
loop {
let x = &mut [1]; // < this array
if done_y {
z = x;
break;
}
y = Some(x);
done_y = true;
}
some_const_fn(y, z); // some_const_fn expects that y to not alias z.
};
```
r? @pnkfelix @nikomatsakis
closes #52671
cc #51823
|
|
Add test for unexpected region for local data ReStatic
Fixes #49579.
r? @pnkfelix @nikomatsakis
|
|
Add test for NLL: unexpected "free region `` does not outlive" error
Fixes #49824.
r? @pnkfelix @nikomatsakis
|
|
|
|
|
|
|
|
After talking about the PR with eddyb, I decided it was best to try to
have some test cases that simplify the problem down to its core, so
that people trying to understand what the issue is here will see those
core examples first.
|
|
|
|
|
|
(Presumably the place that borrow_check ends up reporting for the
error about is no longer the root `Local` itself, and thus the note
diagnostic here stops firing.)
|
|
|
|
These migration lints aren't all up to par in terms of a good migration
experience. Some, like `unreachable_pub`, hit bugs like #52665 and unprepared
macros to be handled enough of the time. Others like linting against
`#[macro_use]` are swimming upstream in an ecosystem that's not quite ready (and
slightly buggy pending a few current PRs).
The general idea is that we will continue to recommend the `rust_2018_idioms`
lint group as part of the transition guide (as an optional step) but we'll be
much more selective about which lints make it into this group. Only those with a
strong track record of not causing too much churn will make the cut.
cc #52679
|
|
rustc: Handle linker diagnostics from LLVM
Previously linker diagnostic were being hidden when two modules were linked
together but failed to link. This commit fixes the situation by ensuring that we
have a diagnostic handler installed and also adds support for handling linker
diagnostics.
|
|
resolve/expansion: Implement tool attributes
|
|
Rollup of 30 pull requests
Successful merges:
- #52340 (Document From trait implementations for OsStr, OsString, CString, and CStr)
- #52628 (Cleanup some rustdoc code)
- #52732 (Remove unstable and deprecated APIs)
- #52745 (Update clippy to latest master)
- #52771 (Clarify thread::park semantics)
- #52778 (Improve readability of serialize.rs)
- #52810 ([NLL] Don't make "fake" match variables mutable)
- #52821 (pretty print for std::collections::vecdeque)
- #52822 (Fix From<LocalWaker>)
- #52824 (Fix -Wpessimizing-move warnings in rustllvm/PassWrapper)
- #52825 (Make sure #47772 does not regress)
- #52831 (remove references to AUTHORS.txt file)
- #52842 (update comment)
- #52846 (Add timeout to use of `curl` in bootstrap.py.)
- #52851 (Make the tool_lints actually usable)
- #52853 (Improve bootstrap help on stages)
- #52859 (Use Vec::extend in SmallVec::extend when applicable)
- #52861 (Add targets for HermitCore (https://hermitcore.org) to the Rust compiler and port libstd to it.)
- #52867 (releases.md: fix 2 typos)
- #52870 (Implement Unpin for FutureObj and LocalFutureObj)
- #52876 (run-pass/const-endianness: negate before to_le())
- #52878 (Fix wrong issue number in the test name)
- #52883 (Include lifetime in mutability suggestion in NLL messages)
- #52888 (Use suggestions for shell format arguments)
- #52904 (NLL: sort diagnostics by span)
- #52905 (Fix a typo in unsize.rs)
- #52907 (NLL: On "cannot move out of type" error, print original before rewrite)
- #52914 (Only run the sparc-abi test on sparc)
- #52918 (Backport 1.27.2 release notes)
- #52929 (Update compatibility note for 1.28.0 to be correct)
Failed merges:
r? @ghost
|
|
Only run the sparc-abi test on sparc
It is not required for LLVM to have SPARC target support, so it is
necessary to only run this test when LLVM does support SPARC. Sadly, it
isn’t possible to specify exactly this constraint. Instead, we specify
that this test should run on SPARC host only (it surely is sane
assumption to make that compiler running on a SPARC can generate
SPARC, right?)
Since you cannot specify multiple `only-*` to have it run on both 32-bit
and 64-bit SPARC we pick 64-bit SPARC, because it is exactly what is
being tested by this test.
Fixes #52881
|
|
pnkfelix:issue-52877-original-source-should-precede-suggestions, r=petrochenkov
NLL: On "cannot move out of type" error, print original before rewrite
NLL: On "cannot move out of type" error, print original source before rewrite.
* Arguably this change is sometimes injecting noise into the output (namely in the cases where the suggested rewrite is inline with the suggestion and we end up highlighting the original source code). I would not be opposed to something more aggressive/dynamic, like revising the suggestion code to automatically print the original source when necessary (e.g. when the error does not have a span that includes the span of the suggestion).
* Also, as another note on this change: The doc comment for `Diagnostic::span_suggestion` says:
```rust
/// The message
///
/// * should not end in any punctuation (a `:` is added automatically)
/// * should not be a question
/// * should not contain any parts like "the following", "as shown"
```
* but the `:` is *not* added when the emitted line appears out-of-line relative to the suggestion. I find that to be an unfortunate UI experience.
----
As a drive-by fix, also changed code to combine multiple suggestions for a pattern into a single multipart suggestion (which vastly improves user experience IMO).
----
Includes the updates to expected NLL diagnostics.
Fix #52877
|
|
NLL: sort diagnostics by span
Sorting the output diagnostics by span is a long planned revision to the NLL diagnostics that we hope will yield a less surprising user experience in some case.
Once we got them buffered, it was trivial to implement. (The hard part is skimming the resulting changes to the diagnostics to make sure nothing broke... Note that I largely rubber-stamped the `#[rustc_regions]` output change.)
Fix #51167
|
|
Use suggestions for shell format arguments
Follow up to #52649.
|
|
Include lifetime in mutability suggestion in NLL messages
Fix #52880.
|
|
Fix wrong issue number in the test name
I made a mistake in previous PR #52620, second issue number was wrong, changing from #52133 to #52113
r? @kennytm
|
|
run-pass/const-endianness: negate before to_le()
`const LE_I128` needs parentheses to negate the value *before* calling
`to_le()`, otherwise it doesn't match the operations performed in the
black-boxed part of the test. This only makes a tangible difference on
big-endian targets.
|
|
Make the tool_lints actually usable
cc #44690
Necessary for rust-lang-nursery/rust-clippy#2955 and rust-lang-nursery/rust-clippy#2977
This PR makes it possible for lint tools (at the moment only for Clippy) to implement the `tool_lints`, like it was documented in #52018.
Because the `declare_lint` macro is pretty cluttered right now, there was not really a good way to add the `tool_name` as an additional argument of the macro. That's why I chose to introduce the new `declare_tool_lint` macro.
The switch from `&str` to `String` in the `lint_groups` `FxHashMap` is because I got weird error messages in the `check_lint_name` method. And the `by_name` field of the `LintStore` also uses `String`.
### What comes with this PR:
If this PR lands and Clippy switches to the `tool_lints`, the currently used methods
```rust
#[cfg_attr(feature = "cargo-clippy", allow(clippy_lint))]
#[allow(unknown_lints, clippy_lint)]
```
to `allow`/`warn`/`deny`/`forbid` Clippy lints, won't have any effects anymore, but also won't produce a warning. That is because the name of `clippy_lint` will then be `clippy::clippy_lint`. (Maybe we can add a clippy lint to search for `cfg_attr` appearances with the `cargo-clippy` feature?)
r? @oli-obk
|
|
Make sure #47772 does not regress
Mostly to make my life in https://github.com/rust-lang/rust/pull/52206 harder.^^
Or should I just add that test there?
|
|
[NLL] Don't make "fake" match variables mutable
These variables can't be mutated by the user, but since they have names the unused-mut lint thinks that it should check them.
|
|
Cleanup some rustdoc code
Commits are mostly individual though some do depend on others.
|
|
rustc: Disallow machine applicability in foreign macros
Recent changes to lints disallowed lints from being emitted against code located
in foreign macros, except for future-incompatible lints. For a future
incompatible lint, however, the automatic suggestions may not be applicable!
This commit updates this code path to force all applicability suggestions made
to foreign macros to never be `MachineApplicable`. This should avoid rustfix
actually attempting fixing these suggestions, causing non-compiling code to be
produced.
Closes rust-lang/cargo#5799
|
|
|
|
|
|
|
|
resolve: Modularize crate-local `#[macro_export] macro_rules`
Based on https://github.com/rust-lang/rust/pull/50911, cc https://github.com/rust-lang/rust/pull/50911#issuecomment-401151270
`#[macro_export] macro_rules` items are collected from the whole crate and are planted into the root module as items, so the external view of the crate is symmetric with its internal view and something like `$crate::my_macro` where `my_macro` is `#[macro_export] macro_rules` works both locally and from other crates.
Closes https://github.com/rust-lang/rust/issues/52726
|
|
live across a yield terminator
|
|
|
|
It is not required for LLVM to have SPARC target support, so it is
necessary to only run this test when LLVM does support SPARC. Sadly, it
isn’t possible to specify exactly this constraint. Instead, we specify
that this test should run on SPARC host only (it surely is sane
assumption to make that compiler running on a SPARC can generate
SPARC, right?)
Since you cannot specify multiple `only-*` to have it run on both 32-bit
and 64-bit SPARC we pick 64-bit SPARC, because it is exactly what is
being tested by this test.
Fixes #52881
|
|
This avoids a redundant length check in some cases when calling
`Vec::truncate` or `Vec::clear`.
Fixes #51802
|
|
Previously linker diagnostic were being hidden when two modules were linked
together but failed to link. This commit fixes the situation by ensuring that we
have a diagnostic handler installed and also adds support for handling linker
diagnostics.
|
|
* Arguably this change is sometimes injecting noise into the output
(namely in the cases where the suggested rewrite is inline with the
suggestion and we end up highlighting the original source code).
I would not be opposed to something more aggressive/dynamic, like
revising the suggestion code to automatically print the original
source when necessary (e.g. when the error does not have a span
that includes the span of the suggestion).
* Also, as another note on this change: The doc comment for `Diagnostic::span_suggestion`
says:
/// The message
///
/// * should not end in any punctuation (a `:` is added automatically)
/// * should not be a question
/// * should not contain any parts like "the following", "as shown"
but the `:` is *not* added when the emitted line appears
out-of-line relative to the suggestion. I find that to be an
unfortunate UI experience.
----
As a drive-by fix, also changed code to combine multiple suggestions
for a pattern into a single multipart suggestion (which vastly
improves user experience IMO).
----
Includes the updates to expected NLL diagnostics.
|
