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 5 pull requests #57888

Merged
merged 22 commits into from
Jan 25, 2019
Merged

Rollup of 5 pull requests #57888

merged 22 commits into from
Jan 25, 2019

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Jan 25, 2019

Successful merges:

Failed merges:

r? @ghost

frewsxcv and others added 22 commits November 25, 2018 12:54
- Original bug about documenting grammar
  - rust-lang#32243
- Known bug with parsing
  - rust-lang#31407
This commit extends previous work in rust-lang#55007 where the name from the
visible parent was used for modules. Now, we also print the name from
the visible parent for types.
MonoItemExt#to_string is used for both debug logging and LLVM symbol
name generation. When debugging, we want to print out any type we
encounter, even if it's something weird like GeneratorWitness. However,
during codegen, we still want to error if we encounter an unexpected
type when generating a name.

To resolve this issue, this commit introduces a new 'debug' parameter to
the relevant methods. When set to 'true', it allows any type to be
printed - when set to 'false', it 'bug!'s when encountering an
unexpected type.

This prevents an ICE when enabling debug logging (via RUST_LOG) while
running rustc on generator-related code.
When trying to use a value after move, instead of using a note, point
at the local declaration that has a type that doesn't implement `Copy`
trait.
…ietMisdreavus

Add grammar in docs for {f32,f64}::from_str, mention known bug.

- Original bug about documenting grammar
  - rust-lang#32243
- Known bug with parsing
  - rust-lang#31407
…sakis

When using value after move, point at span of local

When trying to use a value after move, instead of using a note, point
at the local declaration that has a type that doesn't implement `Copy`
trait.

```
error[E0382]: use of moved value: `x`
  --> $DIR/issue-34721.rs:27:9
   |
LL |     pub fn baz<T: Foo>(x: T) -> T {
   |                -       - move occurs because `x` has type `T`, which does not implement the `Copy` trait
   |                |
   |                consider adding a `Copy` constraint to this type argument
LL |         if 0 == 1 {
LL |             bar::bar(x.zero())
   |                      - value moved here
LL |         } else {
LL |             x.zero()
   |             - value moved here
LL |         };
LL |         x.zero()
   |         ^ value used here after move
```

Fix rust-lang#34721.
Update/remove some old readmes

r? @nikomatsakis

cc rust-lang#48478

There are a bunch of READMEs with content that I would like to see a final decision made on:
- https://github.com/rust-lang/rust/tree/master/src/librustc/ty/query
- https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph
- https://github.com/rust-lang/rust/blob/master/src/librustc/infer/region_constraints
- https://github.com/rust-lang/rust/tree/master/src/librustc/infer/higher_ranked
- https://github.com/rust-lang/rust/tree/master/src/librustc/infer/lexical_region_resolve
- https://github.com/rust-lang/rust/blob/master/src/librustc_borrowck/borrowck

It's not clear how useful or obsolete any of these are. I would really appreciate if the appropriate domain experts for each of these could respond with one of (a) delete it, (b) wait for system to be remove, or (c) move it to rustc-guide. @nikomatsakis do you know who to ping for any of these (sorry, I suspect many of them are you)?
Print visible name for types as well as modules.

Fixes rust-lang#56943 and fixes rust-lang#57713.

This commit extends previous work in rust-lang#55007 where the name from the
visible parent was used for modules. Now, we also print the name from
the visible parent for types.

r? @estebank
Don't ICE when logging unusual types

MonoItemExt#to_string is used for both debug logging and LLVM symbol
name generation. When debugging, we want to print out any type we
encounter, even if it's something weird like GeneratorWitness. However,
during codegen, we still want to error if we encounter an unexpected
type when generating a name.

To resolve this issue, this commit introduces a new 'debug' parameter to
the relevant methods. When set to 'true', it allows any type to be
printed - when set to 'false', it 'bug!'s when encountering an
unexpected type.

This prevents an ICE when enabling debug logging (via RUST_LOG) while
running rustc on generator-related code.
@Centril
Copy link
Contributor Author

Centril commented Jan 25, 2019

@bors r+ p=5

@bors
Copy link
Contributor

bors commented Jan 25, 2019

📌 Commit a6fa7de has been approved by Centril

@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 Jan 25, 2019
@bors
Copy link
Contributor

bors commented Jan 25, 2019

⌛ Testing commit a6fa7de with merge a41ade7...

bors added a commit that referenced this pull request Jan 25, 2019
Rollup of 5 pull requests

Successful merges:

 - #56217 (Add grammar in docs for {f32,f64}::from_str, mention known bug.)
 - #57294 (When using value after move, point at span of local)
 - #57652 (Update/remove some old readmes)
 - #57802 (Print visible name for types as well as modules.)
 - #57865 (Don't ICE when logging unusual types)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jan 25, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: Centril
Pushing a41ade7 to master...

@bors
Copy link
Contributor

bors commented Jan 25, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: Centril
Pushing a41ade7 to master...

@bors bors merged commit a6fa7de into rust-lang:master Jan 25, 2019
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 2019
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-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.

7 participants