Skip to content

Rollup of 6 pull requests - #73692

Merged
bors merged 16 commits into
rust-lang:masterfrom
Dylan-DPC-zz:rollup-ehzsbfw
Jun 24, 2020
Merged

Rollup of 6 pull requests#73692
bors merged 16 commits into
rust-lang:masterfrom
Dylan-DPC-zz:rollup-ehzsbfw

Conversation

@Dylan-DPC-zz

Copy link
Copy Markdown

Successful merges:

Failed merges:

r? @ghost

nn1ksand others added 16 commits June 23, 2020 05:01
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.
Closesrust-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.
…r=nikomatsakis
Remove unused crate imports in 2018 edition crates
Closesrust-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.
Closesrust-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)
@Dylan-DPC-zz

Copy link
Copy Markdown
Author

@bors r+ rollup=never p=6

@bors

bors commented Jun 24, 2020

Copy link
Copy Markdown
Collaborator

📌 Commit be8f381 has been approved by Dylan-DPC

@borsbors 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

bors commented Jun 24, 2020

Copy link
Copy Markdown
Collaborator

⌛ Testing commit be8f381 with merge d8ed1b0...

@bors

bors commented Jun 24, 2020

Copy link
Copy Markdown
Collaborator

☀️ Test successful - checks-azure
Approved by: Dylan-DPC
Pushing d8ed1b0 to master...

@borsbors added the merged-by-bors This PR was explicitly merged by bors. label Jun 24, 2020
@bors
bors merged commit d8ed1b0 into rust-lang:masterJun 24, 2020
@cuvipercuviper added this to the 1.46 milestone May 2, 2024
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-borsThis PR was explicitly merged by bors.S-waiting-on-borsStatus: 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.

10 participants

@Dylan-DPC-zz@bors@cuviper@nn1ks@ayazhafiz@JohnTitor@da-x@nrabulinski@ehuss@Dylan-DPC