…tion

…nteger

@lqd commented on rust-lang#114351 asking
if `sort_by_words(lookup)` is computed repeatedly. I was assuming that
rustc should have no difficulties to hoist it automatically outside of
the loop to avoid repeated pure computation, but according to
 https://godbolt.org/z/frs8Kj1rq it seems like I was wrong:
original version seems to have 2 calls per loop iteration
```
.LBB16_3:
        mov     rbx, qword ptr [r13]
        mov     r14, qword ptr [r13 + 8]
        lea     rdi, [rsp + 40]
        mov     rsi, rbx
        mov     rdx, r14
        call    example::sort_by_words
        lea     rdi, [rsp + 64]
        mov     rsi, qword ptr [rsp + 8]
        mov     rdx, qword ptr [rsp + 16]
        call    example::sort_by_words
        mov     rdi, qword ptr [rsp + 40]
        mov     rdx, qword ptr [rsp + 56]
        mov     rsi, qword ptr [rsp + 64]
        cmp     rdx, qword ptr [rsp + 80]
        mov     qword ptr [rsp + 32], rdi
        mov     qword ptr [rsp + 24], rsi
        jne     .LBB16_5
        call    qword ptr [rip + bcmp@GOTPCREL]
        test    eax, eax
        sete    al
        mov     dword ptr [rsp + 4], eax
        mov     rsi, qword ptr [rsp + 72]
        test    rsi, rsi
        jne     .LBB16_8
        jmp     .LBB16_9
```
but the manually hoisted version just 1:
```
.LBB16_3:
        mov     r13, qword ptr [r15]
        mov     r14, qword ptr [r15 + 8]
        lea     rdi, [rsp + 64]
        mov     rsi, r13
        mov     rdx, r14
        call    example::sort_by_words
        mov     rdi, qword ptr [rsp + 64]
        mov     rdx, qword ptr [rsp + 16]
        cmp     qword ptr [rsp + 80], rdx
        mov     qword ptr [rsp + 32], rdi
        jne     .LBB16_5
        mov     rsi, qword ptr [rsp + 8]
        call    qword ptr [rip + bcmp@GOTPCREL]
        test    eax, eax
        sete    bpl
        mov     rsi, qword ptr [rsp + 72]
        test    rsi, rsi
        jne     .LBB16_8
        jmp     .LBB16_9
```
This code is probably not very hot, but there is no reason to leave
such a low hanging fruit.

…ck-lint, r=cjgillot

Expand, rename and improve `incorrect_fn_null_checks` lint

This PR,

 - firstly, expand the lint by now linting on references
 - secondly, it renames the lint `incorrect_fn_null_checks` -> `useless_ptr_null_checks`
 - and thirdly it improves the lint by catching `ptr::from_mut`, `ptr::from_ref`, as well as `<*mut _>::cast` and `<*const _>::cast_mut`

Fixes rust-lang#113601
cc `@est31`

…-2, r=cjgillot

Fix wrong span for trait selection failure error reporting

Fixes rust-lang#113447

parser: more friendly hints for handling `async move` in the 2015 edition

Fixes rust-lang#114219

An error is emitted when encountering an async move block in the 2015 edition.

Another appropriate location to raise an error is after executing [let path = this.parse_path(PathStyle::Expr)?](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/stmt.rs#L152), but it seems somewhat premature to invoke `create_err` at that stage.

…bank

Suggests turbofish in patterns

Fixes rust-lang#114112

r? `@estebank`

…li-obk

const validation: point at where we found a pointer but expected an integer

Instead of validation just printing "unable to turn pointer into bytes", make this a regular validation error that says where in the value the bad pointer was found. Also distinguish "expected integer, got pointer" from "expected pointer, got partial pointer or mix of pointers".

To avoid duplicating things too much I refactored the diagnostics for validity a bit, so that "got uninit, expected X" and "got pointer, expected X" can share the "X" part. Also all the errors emitted for validation are now grouped under `const_eval_validation` so that they are in a single group in the ftl file.

r? `@oli-obk`

[rustc_span][perf] Hoist lookup sorted by words out of the loop.

`@lqd` commented on rust-lang#114351 asking if `sort_by_words(lookup)` is computed repeatedly. I was assuming that rustc should have no difficulties to hoist it automatically outside of the loop to avoid repeated pure computation, but according to
 https://godbolt.org/z/frs8Kj1rq it seems like I was wrong:
original version seems to have 2 calls per loop iteration
```
.LBB16_3:
        mov     rbx, qword ptr [r13]
        mov     r14, qword ptr [r13 + 8]
        lea     rdi, [rsp + 40]
        mov     rsi, rbx
        mov     rdx, r14
        call    example::sort_by_words
        lea     rdi, [rsp + 64]
        mov     rsi, qword ptr [rsp + 8]
        mov     rdx, qword ptr [rsp + 16]
        call    example::sort_by_words
        mov     rdi, qword ptr [rsp + 40]
        mov     rdx, qword ptr [rsp + 56]
        mov     rsi, qword ptr [rsp + 64]
        cmp     rdx, qword ptr [rsp + 80]
        mov     qword ptr [rsp + 32], rdi
        mov     qword ptr [rsp + 24], rsi
        jne     .LBB16_5
        call    qword ptr [rip + bcmp@GOTPCREL]
        test    eax, eax
        sete    al
        mov     dword ptr [rsp + 4], eax
        mov     rsi, qword ptr [rsp + 72]
        test    rsi, rsi
        jne     .LBB16_8
        jmp     .LBB16_9
```
but the manually hoisted version just 1:
```
.LBB16_3:
        mov     r13, qword ptr [r15]
        mov     r14, qword ptr [r15 + 8]
        lea     rdi, [rsp + 64]
        mov     rsi, r13
        mov     rdx, r14
        call    example::sort_by_words
        mov     rdi, qword ptr [rsp + 64]
        mov     rdx, qword ptr [rsp + 16]
        cmp     qword ptr [rsp + 80], rdx
        mov     qword ptr [rsp + 32], rdi
        jne     .LBB16_5
        mov     rsi, qword ptr [rsp + 8]
        call    qword ptr [rip + bcmp@GOTPCREL]
        test    eax, eax
        sete    bpl
        mov     rsi, qword ptr [rsp + 72]
        test    rsi, rsi
        jne     .LBB16_8
        jmp     .LBB16_9
```
This code is probably not very hot, but there is no reason to leave such a low hanging fruit.

fix the span in the suggestion of remove question mark

Fixes rust-lang#114392

Use a more precise span.