inform user where to give a type annotation by csmoe · Pull Request #48198 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation11 Commits4 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.
@csmoe could you show the rustc output both before and after for any of the compile-fail errors? Also, I think you might have to rebase against latest master (git checkout master && git pull && git checkout inform_type_annotations && git rebase master) to get the correct behavior for two ui tests (otherwise the PR won't get merged by bors).
From the look of https://github.com/rust-lang/rust/pull/48198/files#diff-c3cb6b7128630f1f0a30c553e180e677, it tackles part of #47777, but I'd still like to keep that ticket open to extend the output with more information, like pointing where the type annotation should be added (for example).
@estebank
origin:
fn main() { let mut dirty_list = (0..5).collect(); dirty_list.pop(); }
before
error[E0619]: the type of this value must be known in this context
--> t.rs:3:5
|
3 | dirty_list.pop();
| ^^^^^^^^^^
error: aborting due to previous error
after this commit
error[E0282]: type annotations needed
--> t.rs:3:5
|
2 | let mut dirty_list = (0..5).collect();
| -------------- consider giving `dirty_list` a type
3 | dirty_list.pop();
| ^^^^^^^^^^ cannot infer type for `_`
error: aborting due to previous error
It’s really difficult for me to test the rustc on my laptop, I had tried about 9 hours to compile but never succeeded to build it when testing. So I just pulled this request to test my commits by bors(really sorry for the annoying failure message). Is there any way to compile with local llvm installed from linux packages repo?
I’ll update more changes about 2 days later to deal with the failure(Chinese New Year). sorry for the delay.
after this commit:
Love it!
It’s really difficult for me to test the rustc on my laptop, I had tried about 9 hours to compile but never succeeded to build it when testing.
That is highly unusual. It takes me about 20 minutes to compile LLVM on first pull, and after that it doesn't need to be recompiled (until pulling changes to LLVM version from the repo).
So I just pulled this request to test my commits by bors(really sorry for the annoying failure message).
I do the same sometimes when working on multiple branches (wait for travis CI to fail or pass while I keep working).
Is there any way to compile with local llvm installed from linux packages repo?
I don't know, sorry :-/
I’ll update more changes about 2 days later to deal with the failure(Chinese New Year). sorry for the delay.
Don't worry! Take your time and enjoy the holiday. I like the change, I'm looking forward to having it merged. Just ping me once you've cleared the error.
☔ The latest upstream changes (presumably #46714) made this pull request unmergeable. Please resolve the merge conflicts.
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
📌 Commit 4370a58 has been approved by estebank
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Manishearth added a commit to Manishearth/rust that referenced this pull request
Manishearth added a commit to Manishearth/rust that referenced this pull request
bors added a commit that referenced this pull request
Rollup of 17 pull requests
- Successful merges: #48052, #48072, #48082, #48083, #48084, #48106, #48123, #48157, #48185, #48197, #48198, #48206, #48208, #48221, #48258, #48314, #48335
- Failed merges:
So excited for this PR! 💯
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request
bors added a commit that referenced this pull request
Rollup of 12 pull requests
- Successful merges: #47379, #47833, #48106, #48198, #48314, #48325, #48335, #48352, #48354, #48360, #48382, #48397
- Failed merges:
☔ The latest upstream changes (presumably #48399) made this pull request unmergeable. Please resolve the merge conflicts.
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Labels
Status: This is awaiting some action (such as code changes or more information) from the author.