Skip to content

Rollup of 12 pull requests #73680

New issue

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

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

Already on GitHub? # to your account

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
Collaborator

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
Collaborator

bors commented Jun 24, 2020

⌛ Testing commit ac13194 with merge f02c100c814618e80441be649aea7970de2c3c87...

@bors
Copy link
Collaborator

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
# for free to join this conversation on GitHub. Already have an account? # 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.