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

Batch up libsyntax breaking changes #33864

Merged
merged 13 commits into from
May 27, 2016
Merged

Conversation

Manishearth
Copy link
Member

cc #31645

birkenfeld and others added 2 commits May 24, 2016 14:22
This makes the "shadowing labels" warning *not* print the entire loop
as a span, but only the lifetime.

Also makes rust-lang#31719 go away, but does not fix its root cause (the span
of the expanded loop is still wonky, but not used anymore).
This is more idiomatic, putting the caller in charge of whether or not
to panic.
@rust-highfive
Copy link
Collaborator

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

@Manishearth
Copy link
Member Author

@bors r+ p=20

@bors
Copy link
Contributor

bors commented May 25, 2016

📌 Commit 5bc8cdd has been approved by Manishearth

@bors
Copy link
Contributor

bors commented May 25, 2016

⌛ Testing commit 5bc8cdd with merge d2bc653...

@bors
Copy link
Contributor

bors commented May 25, 2016

💔 Test failed - auto-linux-64-nopt-t

@Manishearth
Copy link
Member Author

@petrochenkov

../src/librustc_resolve/lib.rs:610:31: 610:48 error: attempted access of field `explicit_self` on type `&syntax::ast::MethodSig`, but no field with that name was found
../src/librustc_resolve/lib.rs:610                 MethodRibKind(sig.explicit_self.node == SelfKind::Static)
                                                                 ^~~~~~~~~~~~~~~~~
../src/librustc_resolve/lib.rs:610:57: 610:73 error: no associated item named `Static` found for type `syntax::ast::SelfKind` in the current scope
../src/librustc_resolve/lib.rs:610                 MethodRibKind(sig.explicit_self.node == SelfKind::Static)
                                                                                           ^~~~~~~~~~~~~~~~
../src/librustc_resolve/lib.rs:1680:62: 1680:79 error: attempted access of field `explicit_self` on type `&syntax::ast::MethodSig`, but no field with that name was found
../src/librustc_resolve/lib.rs:1680                                                              sig.explicit_self.node ==
                                                                                                 ^~~~~~~~~~~~~~~~~
../src/librustc_resolve/lib.rs:1681:62: 1681:78 error: no associated item named `Static` found for type `syntax::ast::SelfKind` in the current scope
../src/librustc_resolve/lib.rs:1681                                                              SelfKind::Static));
                                                                                                 ^~~~~~~~~~~~~~~~
../src/librustc_resolve/lib.rs:2011:61: 2011:78 error: attempted access of field `explicit_self` on type `&syntax::ast::MethodSig`, but no field with that name was found
../src/librustc_resolve/lib.rs:2011                                                             sig.explicit_self.node ==
                                                                                                ^~~~~~~~~~~~~~~~~
../src/librustc_resolve/lib.rs:2012:61: 2012:77 error: no associated item named `Static` found for type `syntax::ast::SelfKind` in the current scope
../src/librustc_resolve/lib.rs:2012                                                             SelfKind::Static));
                                                                                                ^~~~~~~~~~~~~~~~
error: aborting due to 6 previous errors
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.rustc_resolve] Error 101

looks like a recent change broke your PR?

@petrochenkov
Copy link
Contributor

Looks like it, I'll rebase it this evening.

@petrochenkov
Copy link
Contributor

@Manishearth
I've rebased both my PRs.

@Manishearth
Copy link
Member Author

command line snippet

mergerollup birkenfeld:loop-label-spans 33351 pnkfelix
mergerollup petrochenkov:dotdot 33639 nmatsakis
mergerollup petrochenkov:selfast 33644 nrc
mergerollup kamalmarhubi:codemape-get-filemap-option 33839  nmatsakis

@Manishearth
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented May 26, 2016

📌 Commit 2b73335 has been approved by Manishearth

@bors
Copy link
Contributor

bors commented May 26, 2016

⌛ Testing commit 2b73335 with merge c4dd066...

bors added a commit that referenced this pull request May 26, 2016
@bors
Copy link
Contributor

bors commented May 26, 2016

💔 Test failed - auto-mac-64-opt

@Manishearth
Copy link
Member Author

@petrochenkov pat-tuple-overfield fails

@petrochenkov
Copy link
Contributor

petrochenkov commented May 26, 2016

pat-tuple-overfield fails

I'm sure it passed locally yesterday, something probably changed again, I'm investigating.

@petrochenkov
Copy link
Contributor

This is very strange, the test still passes locally after rebase even if it shouldn't be platform-dependent. I've pushed one more commit, splitting this test into two. Also, maybe let's try a clean rebuild?

@Manishearth
Copy link
Member Author

@bors try clean

@bors
Copy link
Contributor

bors commented May 26, 2016

💔 Test failed - auto-linux-64-opt

@Manishearth
Copy link
Member Author

@bors retry

  • exception

@bors
Copy link
Contributor

bors commented May 26, 2016

⌛ Testing commit 74651d0 with merge e1a647f...

@bors
Copy link
Contributor

bors commented May 26, 2016

💔 Test failed - auto-mac-64-opt

@Manishearth
Copy link
Member Author


failures:

---- [compile-fail] compile-fail/pat-tuple-overfield-1.rs stdout ----

error: compiler encountered internal error
status: exit code: 101
command: x86_64-apple-darwin/stage2/bin/rustc /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/compile-fail/pat-tuple-overfield-1.rs -L x86_64-apple-darwin/test/compile-fail/ --target=x86_64-apple-darwin --error-format json -Z unstable-options -L x86_64-apple-darwin/test/compile-fail/pat-tuple-overfield-1.stage2-x86_64-apple-darwin.compile-fail.libaux -C prefer-dynamic -o x86_64-apple-darwin/test/compile-fail/pat-tuple-overfield-1.stage2-x86_64-apple-darwin --cfg rtopt -C rpath -O -L x86_64-apple-darwin/rt
stdout:
------------------------------------------
thread 'rustc' panicked at 'arithmetic operation overflowed', ../src/librustc/hir/pat_util.rs:53
note: Run with `RUST_BACKTRACE=1` for a backtrace.


------------------------------------------
stderr:
------------------------------------------
{"message":"mismatched types","code":{"code":"E0308","explanation":"\nThis error occurs when the compiler was unable to infer the concrete type of a\nvariable. It can occur for several cases, the most common of which is a\nmismatch in the expected type that the compiler inferred for a variable's\ninitializing expression, and the actual type explicitly assigned to the\nvariable.\n\nFor example:\n\n```compile_fail\nlet x: i32 = \"I am not a number!\";\n//     ~~~   ~~~~~~~~~~~~~~~~~~~~\n//      |             |\n//      |    initializing expression;\n//      |    compiler infers type `&str`\n//      |\n//    type `i32` assigned to variable `x`\n```\n\nAnother situation in which this occurs is when you attempt to use the `try!`\nmacro inside a function that does not return a `Result<T, E>`:\n\n```compile_fail\nuse std::fs::File;\n\nfn main() {\n    let mut f = try!(File::create(\"foo.txt\"));\n}\n```\n\nThis code gives an error like this:\n\n```text\n<std macros>:5:8: 6:42 error: mismatched types:\n expected `()`,\n     found `core::result::Result<_, _>`\n (expected (),\n     found enum `core::result::Result`) [E0308]\n```\n\n`try!` returns a `Result<T, E>`, and so the function must. But `main()` has\n`()` as its return type, hence the error.\n"},"level":"error","spans":[{"file_name":"/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/compile-fail/pat-tuple-overfield-1.rs","byte_start":548,"byte_end":560,"line_start":15,"line_end":15,"column_start":9,"column_end":21,"is_primary":true,"text":[{"text":"        (1, 2, 3, 4) => {} //~ ERROR mismatched types","highlight_start":9,"highlight_end":21}],"label":"expected a tuple with 3 elements, found one with 4 elements","suggested_replacement":null,"expansion":null}],"children":[{"message":"expected type `(_, _, _)`","code":null,"level":"note","spans":[],"children":[],"rendered":null},{"message":"   found type `(_, _, _, _)`","code":null,"level":"note","spans":[],"children":[],"rendered":null}],"rendered":null}
{"message":"mismatched types","code":{"code":"E0308","explanation":"\nThis error occurs when the compiler was unable to infer the concrete type of a\nvariable. It can occur for several cases, the most common of which is a\nmismatch in the expected type that the compiler inferred for a variable's\ninitializing expression, and the actual type explicitly assigned to the\nvariable.\n\nFor example:\n\n```compile_fail\nlet x: i32 = \"I am not a number!\";\n//     ~~~   ~~~~~~~~~~~~~~~~~~~~\n//      |             |\n//      |    initializing expression;\n//      |    compiler infers type `&str`\n//      |\n//    type `i32` assigned to variable `x`\n```\n\nAnother situation in which this occurs is when you attempt to use the `try!`\nmacro inside a function that does not return a `Result<T, E>`:\n\n```compile_fail\nuse std::fs::File;\n\nfn main() {\n    let mut f = try!(File::create(\"foo.txt\"));\n}\n```\n\nThis code gives an error like this:\n\n```text\n<std macros>:5:8: 6:42 error: mismatched types:\n expected `()`,\n     found `core::result::Result<_, _>`\n (expected (),\n     found enum `core::result::Result`) [E0308]\n```\n\n`try!` returns a `Result<T, E>`, and so the function must. But `main()` has\n`()` as its return type, hence the error.\n"},"level":"error","spans":[{"file_name":"/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/compile-fail/pat-tuple-overfield-1.rs","byte_start":602,"byte_end":618,"line_start":16,"line_end":16,"column_start":9,"column_end":25,"is_primary":true,"text":[{"text":"        (1, 2, .., 3, 4) => {} //~ ERROR mismatched types","highlight_start":9,"highlight_end":25}],"label":"expected a tuple with 3 elements, found one with 4 elements","suggested_replacement":null,"expansion":null}],"children":[{"message":"expected type `(_, _, _)`","code":null,"level":"note","spans":[],"children":[],"rendered":null},{"message":"   found type `(_, _, _, _)`","code":null,"level":"note","spans":[],"children":[],"rendered":null}],"rendered":null}
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

------------------------------------------

thread '[compile-fail] compile-fail/pat-tuple-overfield-1.rs' panicked at 'explicit panic', /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/tools/compiletest/src/runtest.rs:2238

ICE? o.o

@petrochenkov
Copy link
Contributor

Ugh. I see why it passed locally, because overflow checks are disabled by default.
I know what is the reason, I'll fix it this evening.
(Where's our list of bugs caught by overflow checking?)

@Manishearth
Copy link
Member Author

@pnkfelix One more for your list!

@petrochenkov
Copy link
Contributor

Updated.

…elix

 This makes the \"shadowing labels\" warning *not* print the entire loop as a span, but only the lifetime.

Also makes rust-lang#31719 go away, but does not fix its root cause (the span of the expanded loop is still wonky, but not used anymore).
 The AST part of rust-lang#33505.
rust-lang#33505 isn't landed yet, so this PR is based on top of it.

r? @nrc

plugin-[breaking-change] cc rust-lang#31645 @Manishearth
…ption, r=nmatsakis

 This is more idiomatic, putting the caller in charge of whether or not
to panic.
@Manishearth
Copy link
Member Author

@bors r+

@bors
Copy link
Contributor

bors commented May 27, 2016

📌 Commit 63dfbdb has been approved by Manishearth

@Manishearth
Copy link
Member Author

@bors force

@bors
Copy link
Contributor

bors commented May 27, 2016

⌛ Testing commit 63dfbdb with merge 36d5dc7...

bors added a commit that referenced this pull request May 27, 2016
@Manishearth
Copy link
Member Author

List for next breaking batch (unplanned as of now):

@pnkfelix
Copy link
Member

(Where's our list of bugs caught by overflow checking?)

Here! https://github.com/pnkfelix/collab-docs/blob/master/rust/arith-overflow-buglist.md

@Manishearth
Copy link
Member Author

Manishearth commented Aug 1, 2016

Next breaking batch will happen soon, including just #34764 unless any more PRs appear.

cc @petrochenkov if you have anything you need merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants