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 17 pull requests #73946

Closed
wants to merge 47 commits into from

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

ChrisDenton and others added 30 commits May 25, 2020 13:53
On Windows the InnoSetup installer was superseded by the MSI installer. It's no longer needed.
WebAssembly supports saturating floating point to integer casts behind a
target feature. The feature is already available on many browsers.
Beginning with 1.45 Rust will start defining the behavior of floating
point to integer casts to be saturating as well. For this Rust
constructs additional checks on top of the `fptoui` / `fptosi`
instructions it emits. Here we introduce the possibility for the codegen
backend to construct saturating casts itself and only fall back to
constructing the checks ourselves if that is not possible.
Use back-ticks instead of quotation marks in docs for the block comment
variant of TokenKind.
Also adds back-ticks when referring to the contents of this collection.
There were a few instances of this pattern:

```rust
while index < vec.len() {
    let item = &vec[index];
    // ...
}
```

These can be indexed at once:

```rust
while let Some(item) = vec.get(index) {
    // ...
}
```

Particularly in `ObligationForest::process_obligations`, this mitigates
a codegen regression found with LLVM 11 (rust-lang#73526).
When a `macro_rules!` macro expands to another `macro_rules!` macro, we
may see `None`-delimited groups in odd places when another crate
deserializes the 'inner' macro. This commit 'unwraps' an outer
`None`-delimited group to avoid breaking existing code.

See rust-lang#73569 (comment)
for more details.

The proper fix is to handle `None`-delimited groups systematically
throughout the parser, but that will require significant work. In the
meantime, this hack lets us fix important hygiene bugs in macros
…omatsakis

Remove legacy InnoSetup GUI installer

On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed.

The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very "legacy" at this point.

Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase.

As a result of removing InnoSetup, this closes rust-lang#24397
Rename TypeckTables to TypeckResults.

Originally suggested by @eddyb.
…trait-soundness, r=nikomatsakis

Don't implement Fn* traits for #[target_feature] functions

Closes rust-lang#72012.
expand: Stop using nonterminals for passing tokens to attribute and derive macros

Make one more step towards fully token-based expansion and fix issues described in rust-lang#72545 (comment).

Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later.

The cost is making pretty-printing of token streams less pretty.
Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway.

Unfortunately, this is not exactly the same thing as rust-lang#73102.
One more observable effect is how `$crate` is printed in the attribute input.
Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see rust-lang#62393 and related PRs).
This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed.

So, I think we should do this regardless, but we need to run crater first.
r? @Aaron1011
…wjasper

Provide more information on duplicate lang item error.

This gives some notes on the location of the files where the lang items were loaded from. Some duplicate lang item errors can be a little confusing, and this might help in diagnosing what has happened.

Here's an example when hitting a bug with Cargo's build-std:

```
error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `try`.
  |
  = note: the lang item is first defined in crate `core` (which `z10` depends on)
  = note: first definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-a764da499c7385f4.rmeta
  = note: second definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-5b082675aea34986.rmeta
```
…petrochenkov

Handle `macro_rules!` tokens consistently across crates

When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition.

This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case.

To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from.

This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (rust-lang#72121 (comment)). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group.

See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
…crichton

Use WASM's saturating casts if they are available

WebAssembly supports saturating floating point to integer casts behind a target feature. The feature is already available on many browsers. Beginning with 1.45 Rust will start defining the behavior of floating point to integer casts to be saturating as well. For this Rust constructs additional checks on top of the `fptoui` / `fptosi` instructions it emits. Here we introduce the possibility for the codegen backend to construct saturating casts itself and only fall back to constructing the checks ourselves if that is not possible.

Resolves part of rust-lang#73591
ast_pretty: Pass some token streams and trees by reference

Salvaged from an intermediate version of rust-lang#73345.
…nishearth

Split and expand nonstandard-style lints unicode unit test.

RFC 2457 requested that the `nonstandard_style` series of linted be adjusted to cover the non_ascii_identifier case. However when i read the code of those implementations, it seems they're already supporting non_ascii_identifiers. But the exact rules is a little different than what's proposed in RFC 2457.

So I splitted and expanded the existing test case to try to exercise every branch in the code. I think it'll also be easier to examine the cases in these unit tests to see whether it's ok to just leave them as is, or some adjustments are needed.

r? @Manishearth
…Simulacrum

Remove defunct `-Z print-region-graph`
…r=jonas-schievink

Fix markdown rendering in librustc_lexer docs

Use back-ticks instead of quotation marks in docs for the block comment variant of TokenKind.

## [Before](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/enum.TokenKind.html#variant.BlockComment) and after

<img width="1103" alt="Screen Shot 2020-06-28 at 1 22 30 PM" src="https://user-images.githubusercontent.com/19642016/85957562-446a8380-b943-11ea-913a-442cf7744083.png">

<img width="1015" alt="Screen Shot 2020-06-28 at 1 28 29 PM" src="https://user-images.githubusercontent.com/19642016/85957566-4af8fb00-b943-11ea-8fef-a09c1d586772.png">

## Question

For visual consistency, should we use back-ticks throughout the docs for these enum variants?
…jonas-schievink

Add newline to rustc MultiSpan docs

Also adds back-ticks when referring to the contents of this collection.
Fix Zulip topic format

Yet another instance of me making a mistake after copy-pasting :D
r? @Dylan-DPC
remove duplicate test for rust-lang#61935

Apparently I somehow messed up the issue number in rust-lang#67890
which caused us to add this test twice, both as https://github.com/rust-lang/rust/blob/master/src/test/ui/const-generics/issues/issue-61935.rs and https://github.com/rust-lang/rust/blob/master/src/test/ui/const-generics/lazy-normalization/issue-71922.rs

rust-lang#61935 is the actually fixed issue while rust-lang#71922 is still not working, as it depends on lazy norm of repeat expressions
…ckler

`#[deny(unsafe_op_in_unsafe_fn)]` in libstd/fs.rs

The `libstd/fs.rs` part of rust-lang#73904 . Wraps the two calls to an unsafe fn `Initializer::nop()` in an `unsafe` block.

Followed instructions in parent issue, ran `./x.py check src/libstd/` after adding the lint and two warnings were given. After adding these changes, those disappear.
Rewrite a few manual index loops with while-let

There were a few instances of this pattern:

```rust
while index < vec.len() {
    let item = &vec[index];
    // ...
}
```

These can be indexed at once:

```rust
while let Some(item) = vec.get(index) {
    // ...
}
```

Particularly in `ObligationForest::process_obligations`, this mitigates
a codegen regression found with LLVM 11 (rust-lang#73526).
@Manishearth
Copy link
Member Author

@rustbot modify labels: +rollup
@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Jul 2, 2020

📌 Commit 30f6fac has been approved by Manishearth

@rustbot rustbot added the rollup A PR which is a rollup label Jul 2, 2020
@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 Jul 2, 2020
@bors
Copy link
Contributor

bors commented Jul 2, 2020

⌛ Testing commit 30f6fac with merge 36a21b8aef13a6e03f277df100062c5ab67039e4...

@bors
Copy link
Contributor

bors commented Jul 2, 2020

💔 Test failed - checks-actions

@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 Jul 2, 2020
@Manishearth
Copy link
Member Author

2020-07-02T02:18:14.9740165Z ---- [ui] ui/numbers-arithmetic/saturating-float-casts-wasm.rs stdout ----
2020-07-02T02:18:14.9740371Z normalized stderr:
2020-07-02T02:18:14.9742250Z warning: the feature `track_caller` has been stable since 1.46.0 and no longer requires an attribute to enable
2020-07-02T02:18:14.9744356Z   --> $DIR/saturating-float-casts-wasm.rs:6:12
2020-07-02T02:18:14.9744835Z    |
2020-07-02T02:18:14.9745118Z LL | #![feature(track_caller)]
2020-07-02T02:18:14.9745396Z    |            ^^^^^^^^^^^^
2020-07-02T02:18:14.9745668Z    |
2020-07-02T02:18:14.9745919Z    = note: `#[warn(stable_features)]` on by default
2020-07-02T02:18:14.9746071Z 
2020-07-02T02:18:14.9746303Z warning: 1 warning emitted
2020-07-02T02:18:14.9746557Z 
2020-07-02T02:18:14.9746693Z 
2020-07-02T02:18:14.9763290Z 
2020-07-02T02:18:14.9763570Z 


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.