Skip to content

Batch up libsyntax breaking changes#33864

Merged
bors merged 13 commits into
rust-lang:masterfrom
Manishearth:breaking-batch
May 27, 2016
Merged

Batch up libsyntax breaking changes#33864
bors merged 13 commits into
rust-lang:masterfrom
Manishearth:breaking-batch

Conversation

@Manishearth

Copy link
Copy Markdown
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
Copy Markdown
Contributor

r? @arielb1

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

@Manishearth

Copy link
Copy Markdown
Member Author

@bors r+ p=20

@bors

bors commented May 25, 2016

Copy link
Copy Markdown
Collaborator

📌 Commit 5bc8cdd has been approved by Manishearth

@bors

bors commented May 25, 2016

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 5bc8cdd with merge d2bc653...

@bors

bors commented May 25, 2016

Copy link
Copy Markdown
Collaborator

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

@Manishearth

Copy link
Copy Markdown
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
Copy Markdown
Contributor

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

@petrochenkov

Copy link
Copy Markdown
Contributor

@Manishearth
I've rebased both my PRs.

@Manishearth

Copy link
Copy Markdown
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
Copy Markdown
Member Author

@bors r+ p=10

@bors

bors commented May 26, 2016

Copy link
Copy Markdown
Collaborator

📌 Commit 2b73335 has been approved by Manishearth

@bors

bors commented May 26, 2016

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 2b73335 with merge c4dd066...

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

bors commented May 26, 2016

Copy link
Copy Markdown
Collaborator

💔 Test failed - auto-mac-64-opt

@Manishearth

Copy link
Copy Markdown
Member Author

@petrochenkov pat-tuple-overfield fails

@petrochenkov

petrochenkov commented May 26, 2016

Copy link
Copy Markdown
Contributor

pat-tuple-overfield fails

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

@petrochenkov

Copy link
Copy Markdown
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
Copy Markdown
Member Author

@bors try clean

@bors

bors commented May 26, 2016

Copy link
Copy Markdown
Collaborator

💔 Test failed - auto-linux-64-opt

@Manishearth

Copy link
Copy Markdown
Member Author

@bors retry

  • exception

@bors

bors commented May 26, 2016

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 74651d0 with merge e1a647f...

@bors

bors commented May 26, 2016

Copy link
Copy Markdown
Collaborator

💔 Test failed - auto-mac-64-opt

@Manishearth

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Member Author

@pnkfelix One more for your list!

@petrochenkov

Copy link
Copy Markdown
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
Copy Markdown
Member Author

@bors r+

@bors

bors commented May 27, 2016

Copy link
Copy Markdown
Collaborator

📌 Commit 63dfbdb has been approved by Manishearth

@Manishearth

Copy link
Copy Markdown
Member Author

@bors force

@bors

bors commented May 27, 2016

Copy link
Copy Markdown
Collaborator

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

bors added a commit that referenced this pull request May 27, 2016
@Manishearth

Copy link
Copy Markdown
Member Author

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

@pnkfelix

Copy link
Copy Markdown
Contributor

(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

Manishearth commented Aug 1, 2016

Copy link
Copy Markdown
Member Author

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