Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 13 pull requests #73511

Merged
merged 46 commits into from
Jun 20, 2020
Merged

Rollup of 13 pull requests #73511

merged 46 commits into from
Jun 20, 2020

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

hbina and others added 30 commits June 13, 2020 15:06
This is just the reverse of shift_head.
We already implicitly (or explicitly??) do the bound checking for the indexing.
re rust-lang#72380 (comment)

Given the toy code

```rust
fn is_positive(n: usize) {
  n > -1_isize;
}
```

We currently get a type mismatch error like the following:

```
error[E0308]: mismatched types
 --> src/main.rs:2:9
  |
2 |     n > -1_isize;
  |         ^^^^^^^^ expected `usize`, found `isize`
  |
help: you can convert an `isize` to `usize` and panic if the converted value wouldn't fit
  |
2 |     n > (-1_isize).try_into().unwrap();
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

But clearly, `-1` can never fit into a `usize`, so the suggestion will
always panic. A more useful message would tell the user that the value
can never fit in the expected type:

```
error[E0308]: mismatched types
 --> test.rs:2:9
  |
2 |     n > -1_isize;
  |         ^^^^^^^^ expected `usize`, found `isize`
  |
note: `-1_isize` can never fit into `usize`
 --> test.rs:2:9
  |
2 |     n > -1_isize;
  |         ^^^^^^^^
```

Which is what this commit implements.

I only added this check for negative literals because

- Currently we can only perform such a check for literals (constant
  value propagation is outside the scope of the typechecker at this
  point)
- A lint error for out-of-range numeric literals is already emitted

IMO it makes more sense to put this check in librustc_lint, but as far
as I can tell the typecheck pass happens before the lint pass, so I've
added it here.

r? @estebank
…xpect`

Currently, `asm!` parsing uses an `expect` for the last parsed
pseudo-keyword (`sym`), which makes it difficult to extend without
simultaneously refactoring. Use `eat` for the last pseudo-keyword, and
then add an `else` that fails parsing. No change to error output.
pprust uses `print_string` to write out the template string, and
`print_string` already calls `escape_debug`, so `impl fmt::Display for
InlineAsmTemplatePiece` shouldn't do an additional `escape_debug`.

This fixes a pretty-printing bug that translated
`asm!("...\n...")`
to
`asm!("...\\n...")`
Previously, we would suggest `Box<Self>` as a valid receiver, even if
method resolution only succeeded due to an autoderef (e.g. to `&self`)
…ated

Allow the `asm!` macro to accept a series of template arguments, and
interpret them as if they were concatenated with a '\n' between them.
This allows writing an `asm!` where each line of assembly appears in a
separate template string argument.

This syntax makes it possible for rustfmt to reliably format and indent
each line of assembly, without risking changes to the inside of a
template string. It also avoids the complexity of having the user
carefully format and indent a multi-line string (including where to put
the surrounding quotes), and avoids the extra indentation and lines of a
call to `concat!`.

For example, rewriting the second example from the [blog post on the new
inline assembly
syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html)
using multiple template strings:

```rust

fn main() {
    let mut bits = [0u8; 64];
    for value in 0..=1024u64 {
        let popcnt;
        unsafe {
            asm!(
                "    popcnt {popcnt}, {v}",
                "2:",
                "    blsi rax, {v}",
                "    jz 1f",
                "    xor {v}, rax",
                "    tzcnt rax, rax",
                "    stosb",
                "    jmp 2b",
                "1:",
                v = inout(reg) value => _,
                popcnt = out(reg) popcnt,
                out("rax") _, // scratch
                inout("rdi") bits.as_mut_ptr() => _,
            );
        }
        println!("bits of {}: {:?}", value, &bits[0..popcnt]);
    }
}
```

Note that all the template strings must appear before all other
arguments; you cannot, for instance, provide a series of template
strings intermixed with the corresponding operands.

In order to get srcloc mappings right for macros that generate
multi-line string literals, create one line_span for each
line in the string literal, each pointing to the macro.

Make `rustc_parse_format::Parser::curarg` `pub`, so that we can
propagate it from one template string argument to the next.
…uments

Update all examples to use the new formatting, and update explanations
to document it.
For the following code
```rust
let c = || bar(foo.x, foo.x)
```

We generate two different `hir::Place`s for both `foo.x`.
Handling this adds overhead for analysis we need to do for RFC 2229.

We also want to store type information at each Projection to support
analysis as part of the RFC. This resembles what we have for
`mir::Place`

This commit modifies the Place as follows:
- Rename to `PlaceWithHirId`, where there `hir_id` is that of the
expressioin.
- Move any other information that describes the access out to another
struct now called `Place`.
- Removed `Span`, it can be accessed using the [hir
API](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.span)
- Modify `Projection` to be a strucutre of its own, that currently only
contains the `ProjectionKind`.

Adding type information to projections wil be completed as part of rust-lang/project-rfc-2229#5

Closes rust-lang/project-rfc-2229#3

Co-authored-by: Aman Arora <[email protected]>
Co-authored-by: Roxane Fruytier <[email protected]>
This commit modifies `transparent_newtype_field` so that it handles
projections with generic parameters, where `normalize_erasing_regions`
would ICE.

Signed-off-by: David Wood <[email protected]>
Opaque types cannot be used in extern declarations, and normally cannot
exist in fields - except with type aliases to `impl Trait` and
projections which normalize to them.

Signed-off-by: David Wood <[email protected]>
This commit applies the changes introduced in rust-lang#72890 to both enum
variants and unions - where the logic prior to rust-lang#72890 was duplicated.

Signed-off-by: David Wood <[email protected]>
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 19, 2020
@bors
Copy link
Contributor

bors commented Jun 19, 2020

⌛ Testing commit a88182f with merge 62767de840c77aca8154a07efb9dcb63c4449ace...

@Manishearth
Copy link
Member Author

BurntSushi/xsv#227

@Mark-Simulacrum
Copy link
Member

We should either disable quickcheck ecosystem tests or perhaps make the seed constant, I think -- I imagine there's some env variable we can set?

@Manishearth
Copy link
Member Author

Oh, that can work too

@Manishearth
Copy link
Member Author

Unrelated: I wonder if we can set up caching so that retrying the same PR won't rerun builds that succeeded?

@Mark-Simulacrum
Copy link
Member

In theory yeah but I imagine it's pretty hard. I have wanted to try sccache for stage 0 at least though which would probably give many of the benefits of your proposal.

@Manishearth
Copy link
Member Author

@bors retry

@bors
Copy link
Contributor

bors commented Jun 19, 2020

⌛ Testing commit a88182f with merge e1a785ee888e44f8fd691fe3348de01760efe4a8...

@bors
Copy link
Contributor

bors commented Jun 19, 2020

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 19, 2020
@Manishearth
Copy link
Member Author

@bors retry force

network

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 19, 2020
@bors
Copy link
Contributor

bors commented Jun 19, 2020

⌛ Testing commit a88182f with merge 34c5cd9...

@bors
Copy link
Contributor

bors commented Jun 20, 2020

☀️ Test successful - checks-azure
Approved by: Manishearth
Pushing 34c5cd9 to master...

@nnethercote
Copy link
Contributor

This merge was a small perf win.

@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.