GitHub PushEvent at 2014-07-03 21:07:30
Repository: rust
Actor: jroweboy
Payload: {"shas":[["d2ff9d804aa0281adc6a8733467616db9cc2fe22","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","Update AUTHORS.txt","Alex Crichton",false],["8dff029f9d155ca9dbc317d362919e5e43c2a232","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","Updated release notes for 0.11.0","Alex Crichton",false],["454b9d2d1f742d25f95b956649a9a6d92b522da4","0f090b00e1f6f00c3ad93f3af1e80f8d76cac273@mimiga.net","librustc: Fix `expr_use_visitor` (and, transitively, the borrow check)\nwith overloaded calls.\n\nThis enforces the mutability and borrow restrictions around overloaded\ncalls.\n\nCloses #14774.\n\n[breaking-change]","Patrick Walton",true],["9af1b0e5e1a0f3efb3773ae857e280cb9d099afe","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","travis: Move from travis_wait to time-passes\n\nIt's looking like we're still timing out all over the place with travis_wait\nbecause the entire `make -j4 rustc-stage1` command is taking too long. Instead,\nachieve roughly the same idea by just having `-Z time-passes` printing\ninformation. We shouldn't have a pass that takes longer than 10 minutes in\nisolation.","Alex Crichton",true],["e56dbad9f7c3691bcb12edfaeda5cb3b660496de","0f090b00e1f6f00c3ad93f3af1e80f8d76cac273@mimiga.net","librustc: Properly compare implementation method type parameter bounds\nwith the corresponding trait parameter bounds.\n\nThis is a version of the patch in PR #12611 by Florian Hahn, modified to\naddress Niko's feedback.\n\nIt does not address the issue of duplicate type parameter bounds, nor\ndoes it address the issue of implementation-defined methods that contain\n*fewer* bounds than the trait, because Niko's review indicates that this\nshould not be necessary (and indeed I believe it is not). A test has\nbeen added to ensure that this works.\n\nThis will break code like:\n\n    trait Foo {\n        fn bar<T:Baz>();\n    }\n\n    impl Foo for Boo {\n        fn bar<T:Baz + Quux>() { ... }\n        //             ^~~~ ERROR\n    }\n\nThis will be rejected because the implementation requires *more* bounds\nthan the trait. It can be fixed by either adding the missing bound to\nthe trait:\n\n    trait Foo {\n        fn bar<T:Baz + Quux>();\n        //             ^~~~\n    }\n\n    impl Foo for Boo {\n        fn bar<T:Baz + Quux>() { ... }  // OK\n    }\n\nOr by removing the bound from the impl:\n\n    trait Foo {\n        fn bar<T:Baz>();\n    }\n\n    impl Foo for Boo {\n        fn bar<T:Baz>() { ... }  // OK\n        //       ^ remove Quux\n    }\n\nThis patch imports the relevant tests from #2687, as well as the test\ncase in #5886, which is fixed as well by this patch.\n\nCloses #2687.\nCloses #5886.\n\n[breaking-change]","Patrick Walton",true],["c85d42a3054e2859aac67b143485f6cd8a0693e9","47207a6890ade34efd755d6d630f1c4e984fc02d@sector5d.org","Fix example in docs on documentation","Derecho",true],["40e05413096bbd5f35e566e796f525742076600f","4fb647a2c3ead3c3f40f455abb861941f7d4ffb2@posteo","debuginfo: Make names of types in debuginfo reliable and omit source locations from debug info type descriptions.\n\nSo far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.\nThis commit makes the debuginfo module responsible for creating type names instead of using ppaux::ty_to_str() and brings type names, as they show up in the DWARF information, in line with GCC and Clang:\n\n* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.\n* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.\n\nCare is also taken to reliably make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.\n\nThis commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.\nFortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be reenabled for type descriptions.","Michael Woerister",true],["fb560c673d5ed9edf81a1782c4c9273cf08002f6","b37e819222e608cb8bfbe2a3fe20f789456b0ed9@gmail.com","Rationals that have a 1 denom should print like ints","Paolo Falabella",true],["169c988d09a9d4e46de2b7fead9489e94964c7c7","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15222 : alexcrichton/rust/relnotes, r=brson\n\nDetailed notes have their skeleton [on the wiki](https://github.com/rust-lang/rust/wiki/Doc-detailed-release-notes) (and need filling out).","bors",false],["3035d8dfb13077e195eb056568183911c90c1b4b","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15313 : pcwalton/rust/overloaded-call-expr-use, r=alexcrichton\n\nwith overloaded calls.\r\n\r\nThis enforces the mutability and borrow restrictions around overloaded\r\ncalls.\r\n\r\n[breaking-change]\r\n\r\nCloses #12223.\r\n\r\nr? @alexcrichton","bors",true],["c0248c0839cfdf5b7030f4191ea7aed0981b9e4e","54090f63eeca41fad9b2ca1659fcc53377227dd0@dei.uc.pt","Fix rotate_{left, right} for multiple of bitsize rotation amounts\n\nAdd additional rotation tests","Samuel Neves",true],["c8ae065182d19a098aa397fddcb4f4f4eccc0b32","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15323 : alexcrichton/rust/no-travis-wait, r=huonw\n\nIt's looking like we're still timing out all over the place with travis_wait\r\nbecause the entire `make -j4 rustc-stage1` command is taking too long. Instead,\r\nachieve roughly the same idea by just having `-Z time-passes` printing\r\ninformation. We shouldn't have a pass that takes longer than 10 minutes in\r\nisolation.","bors",true],["ccd7aaf17a4fa3c4851758ec70ffa755e25455be","c03dbf38338ca083712bad5c5e84bc5b271c0654@gmail.com","install: Correct libdir for Windows installs.\n\nPlatform-detection code from `configure` copied over to `install.sh`\nin order to special case the lib dir being `bin` on Windows instead\nof `lib`.\n\nShort-term fix for #13810.","Mike Boutin",true],["67776ba3dab24a3e281931da437d30ccfc3b04c1","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15325 : pcwalton/rust/trait-impl-bound-mismatch, r=pnkfelix\n\nwith the corresponding trait parameter bounds.\r\n\r\nThis is a version of the patch in PR #12611 by Florian Hahn, modified to\r\naddress Niko's feedback.\r\n\r\nIt does not address the issue of duplicate type parameter bounds, nor\r\ndoes it address the issue of implementation-defined methods that contain\r\n*fewer* bounds than the trait, because Niko's review indicates that this\r\nshould not be necessary (and indeed I believe it is not). A test has\r\nbeen added to ensure that this works.\r\n\r\nThis will break code like:\r\n\r\n    trait Foo {\r\n        fn bar<T:Baz>();\r\n    }\r\n\r\n    impl Foo for Boo {\r\n        fn bar<T:Baz + Quux>() { ... }\r\n        //             ^~~~ ERROR\r\n    }\r\n\r\nThis will be rejected because the implementation requires *more* bounds\r\nthan the trait. It can be fixed by either adding the missing bound to\r\nthe trait:\r\n\r\n    trait Foo {\r\n        fn bar<T:Baz + Quux>();\r\n        //             ^~~~\r\n    }\r\n\r\n    impl Foo for Boo {\r\n        fn bar<T:Baz + Quux>() { ... }  // OK\r\n    }\r\n\r\nOr by removing the bound from the impl:\r\n\r\n    trait Foo {\r\n        fn bar<T:Baz>();\r\n    }\r\n\r\n    impl Foo for Boo {\r\n        fn bar<T:Baz>() { ... }  // OK\r\n        //       ^ remove Quux\r\n    }\r\n\r\nThis patch imports the relevant tests from #2687, as well as the test\r\ncase in #5886, which is fixed as well by this patch.\r\n\r\nCloses #2687.\r\nCloses #5886.\r\n\r\n[breaking-change]\r\n\r\nr? @pnkfelix","bors",true],["e6c54a12c4d209de9f438b4722657ca381f969a2","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15087 : iliekturtles/rust/13810-make-install-mingw32, r=brson\n\nShort-term fix per @brson's comment: https://github.com/rust-lang/rust/issues/13810#issuecomment-43562843. Tested on Win7 x64 and Linux.\r\n\r\nOne possible issue is that `install.sh` doesn't have a `need_cmd` definition like `configure` does. Should this be ported over as well?\r\n\r\nPlatform-detection code from `configure` copied over to `install.sh` in\r\norder to special case the lib dir being `bin` on Windows instead of\r\n`lib`.\r\n\r\nShort-term fix for #13810.","bors",true],["00f9ff2b41ffd1f1c187533570d979018724852a","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15324 : sneves/rust/master, r=alexcrichton\n\nThe current implementation of `rotate_left` and `rotate_right` are incorrect when the rotation amount is 0, or a multiple of the input's bitsize. When `n = 0`, the expression\r\n\r\n    (self >> n) | (self << ($BITS - n))\r\n\r\nresults in a shift left by `$BITS` bits, which is undefined behavior (see https://github.com/rust-lang/rust/issues/10183), and currently results in a hardcoded `-1` value, instead of the original input value. Reducing `($BITS - n)` modulo `$BITS`, simplified to `(-n % $BITS)`, fixes this problem.","bors",true],["6b6edf4702be1a3c984e894cfb568b63ca224a26","1d3764b91b902f6b45836e2498da81fe35caf6d6@jakub.cc","Improve code reuse between trans/_match.rs and check_match.rs\n\nThe specialization logic for patterns is really the same in both\nexhaustiveness/reachability checking and codegen.","Jakub Wieczorek",true],["e26d0a7a36439497ccc6994110e97d79c924c2d7","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15078 : jakub-/rust/pattern-matching-refactor-vol-2, r=pnkfelix\n\nI believe there's more commonality to be found there but maybe small steps are better. I'm also in the process of documenting what I can, I will see if I can add it to this PR.\r\n\r\nIt also seems to me that ideally some of this stuff (especially the pattern sanity check) could live as a separate compiler-agnostic module but I understand this may not be the right time (if not the worst) to start the process of modularising rustc.","bors",true],["550cc045e2241005f9de3034a412cf3ae162d453","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15199 : michaelwoerister/rust/cross-crate-stability, r=luqmana\n\nSo far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.\r\nThis commit makes the debuginfo module responsible for creating type names instead of using `ppaux::ty_to_str()` and brings type names (as they show up in the DWARF information) in line with GCC and Clang:\r\n\r\n* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.\r\n* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.\r\n\r\nCare is also taken to make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.\r\n\r\nThis commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.\r\nFortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be re-enabled for type descriptions.\r\n\r\n`RUSTFLAGS=-g make check` no works again for me locally, including the LTO test cases (note that I've taken care of #15156 by reverting the change in LLVM that @luqmana identified as the culprit for that issue).","bors",true],["524f4699434bca99a577bd15ddea41f96b864726","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #15331 : Derecho/rust/master, r=alexcrichton\n\nOne of the examples in the docs on adding documentation to rust code has an error that will cause the function to run endlessly rather than return the desired result, should someone actually implement this for some reason. While the error does not hinder the explanation of documenting code, it does look better if it is corrected.","bors",true]],"size":24,"ref":"refs/heads/master","head":"6b210878a19ffcc806e285f6678a2883eaf407b6"}