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 12 pull requests #73680

Closed
wants to merge 29 commits into from

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

mati865 and others added 29 commits June 19, 2020 16:16
Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.

Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.

A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in rust-lang#60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.

Closes rust-lang#73553
In the following example, an inaccessible path is suggested via
`use foo::bar::X;` whereas an accessible public exported path can
be suggested instead.

```
mod foo {
    mod bar {
        pub struct X;
    }
    pub use self::bar::X;
}

fn main() { X; }
```

This fixes the issue.
Context: this is needed to fix rust-lang/rustfmt#4263,
which currently records the span of a const generic param incorrectly
because the location of the `const` kw is not known.

I am not sure how to add tests for this; any guidance in how to do so
would be appreciated 🙂
… r=matthewjasper

Cleanup MinGW LLVM linkage workaround

LLVM correctly passes `uuid` for a long time, GCC unwinding library (either static or dynamic) comes from [windows_gnu_base](https://github.com/rust-lang/rust/blob/06e47688bf15d0215edbe05b21603062f6d2eb5d/src/librustc_target/spec/windows_gnu_base.rs).
Fix handling of reserved registers for ARM inline asm

`r6` is now disallowed as an operand since LLVM sometimes uses it as a base pointer.

The check against using the frame pointer as an operand now takes the platform into account and will block either `r7` or `r11` as appropriate.

Fixes rust-lang#73450

cc @cbiffle
…morse

Record span of `const` kw in GenericParamKind

Context: this is needed for a fix of rust-lang/rustfmt#4263,
which currently records the span of a const generic param incorrectly
because the location of the `const` kw is not known.

I am not sure how to add tests for this; any guidance in how to do so
would be appreciated 🙂
…abnik

Document the mod keyword

Partial fix for rust-lang#34601 .

Documentation for the `mod` keyword.
Add UI test for issue 73592

It happens that rust-lang#72280 accidentally fixed a bug which is later discovered in rust-lang#73592. This PR adds a UI test to prevent future regression.

Closes rust-lang#73592
…r=nikomatsakis

Remove unused crate imports in 2018 edition crates

Closes rust-lang#73570
Change heuristic for determining range literal

Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.

Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.

A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in rust-lang#60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.

Closes rust-lang#73553
…ons, r=petrochenkov

Add re-exports to use suggestions

In the following example, an inaccessible path is suggested via `use foo::bar::X;` whereas an accessible public exported path can be suggested instead.

```rust
mod foo {
    mod bar {
        pub struct X;
    }
    pub use self::bar::X;
}

fn main() { X; }
```

This fixes the issue.
Update books

## reference

5 commits in 5d40ba5c2515caffa7790cda621239dc21ef5a72..04d5d5d7ba624b6f5016298451f3a63d557f3260
2020-06-06 20:25:36 -0700 to 2020-06-16 15:08:05 -0700
- Mention `feature="foo"` is a Cargo convention. (rust-lang/reference#833)
- fix out of date info on type aliases (rust-lang/reference#831)
- Fix an invalid variable name in the loop example (rust-lang/reference#832)
- Fix note about using proc_macro with Cargo. (rust-lang/reference#815)
- Add a link to the definition of Pattern_White_Space. (rust-lang/reference#824)

## book

7 commits in 30cd9dfe71c446de63826bb4472627af45acc9db..4e7c00bece1544d409312ec93467beb62b5bd0cb
2020-06-07 23:07:19 -0500 to 2020-06-19 09:39:12 -0400
- Link to the reference file that exists
- Link to the reference
- Clean up discussion around advanced lifetime stuff (rust-lang/book#2351)
- Reword Chapter 6 page 2, match (rust-lang/book#2374)
- Clarify some package/crate distinctions in chapter 14 (rust-lang/book#2373)
- Not mandatory with cargo 1.41.0-nightly (rust-lang/book#2368)
- Use same naming for Rhs as libcore/ops (rust-lang/book#2371)

## rust-by-example

4 commits in 7aa82129aa23e7e181efbeb8da03a2a897ef6afc..6f94ccb48da6fa4ed0031290f21411cf789f7d5e
2020-05-25 14:54:26 -0300 to 2020-06-20 17:51:30 -0300
- Update to mdbook 0.3.7 (rust-lang/rust-by-example#1352)
- Update fn.md (rust-lang/rust-by-example#1351)
- Fixed typo in formatted print (rust-lang/rust-by-example#1350)
- This explanation incorrectly inverts the meaning of SuperTrait (rust-lang/rust-by-example#1349)

## embedded-book

5 commits in 5555a97f04ad7974ac6fb8fb47c267c4274adf4a..616962ad0dd80f34d8b802da038d0aed9dd691bb
2020-05-25 18:00:51 +0000 to 2020-06-23 16:03:45 +0000
- Update RTFM name to RTIC, fixed links, updated singletons.md example.  (rust-embedded/book#254)
- Note on how to rebuild if memory.x is changed  (rust-embedded/book#253)
- Ease the readers into the Discovery book  (rust-embedded/book#250)
- Provide a note on 'extern crate' usage in edition 2018 syntax of Rust  (rust-embedded/book#248)
- Fix Typos and Improve Readability  (rust-embedded/book#245)
@Manishearth
Copy link
Member Author

@bors r+ p=5 rollup=never

@bors
Copy link
Contributor

bors commented Jun 24, 2020

📌 Commit ac13194 has been approved by Manishearth

@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 24, 2020
@bors
Copy link
Contributor

bors commented Jun 24, 2020

⌛ Testing commit ac13194 with merge f02c100c814618e80441be649aea7970de2c3c87...

@bors
Copy link
Contributor

bors commented Jun 24, 2020

💥 Test timed out

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

Aw, the build succeeded too. @pietroalbini in case random CI timeouts aren't on your radar

@ayazhafiz
Copy link
Contributor

@Manishearth can we expect commits that failed to be merged will be rolled up in another PR?

@Manishearth
Copy link
Member Author

@ayazhafiz yes, eventually. You can check the queue at http://buildbot2.rust-lang.org/homu/queue/rust

@Manishearth Manishearth deleted the rollup-g8q9ges branch July 18, 2020 01:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.