GitHub PushEvent at 2014-03-25 03:07:07
Repository: rust
Actor: alexcrichton
Payload: {"shas":[["57ac379a630d9756c71f2747debe1756ccf62c5f","8de0203a6391036bc81ce266eefac1291b6bcb9a@pnkfx.org","Correct overly broad definition of `'static` kind bound.\n\nWhile double-checking my understanding of the meaning of `'static`,\nI made the following test program:\n\n```rust\nfn foo<X:'static>(_x: X) { }\n\n#[cfg(not(acceptable))]\nfn bar() {\n    let a = 3;\n    let b = &a;\n    foo(b);\n}\n\n#[cfg(acceptable)]\nfn bar() {\n    static c : int = 4;;\n    let d : &'static int = &c;\n    foo(d);\n}\n\nfn main() {\n    bar();\n}\n```\n\nTranscript of compiling above program, illustrating that the `--cfg\nacceptable` variant of `bar` compiles successfully, showing that the\n`'static` kind bound only disallows non-`static` references, not *all*\nreferences:\n\n```\n% rustc --version\n/Users/fklock/opt/rust-dbg/bin/rustc 0.10-pre (caf17fe 2014-03-21 02:21:50 -0700)\nhost: x86_64-apple-darwin\n% rustc /tmp/s.rs\n/tmp/s.rs:7:5: 7:8 error: instantiating a type parameter with an incompatible type `&int`, which does not fulfill `'static`\n/tmp/s.rs:7     foo(b);\n                ^~~\nerror: aborting due to previous error\n% rustc --cfg acceptable /tmp/s.rs\n% ./s\n%\n```\n\n(Note that the explicit type annotation on `let d : &'static int` is\nnecessary; it did not suffice for me to just write `let d = &'static\nc;`.  That might be a latent bug, I am not sure yet.)\n\nAnyway, a fix to the documentation seemed prudent.","Felix S. Klock II",true],["e6468a82151c073130dc1c6517890bb41929ad11","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13113 : pnkfelix/rust/correct-static-kind-doc, r=huonw\n\nWhile double-checking my understanding of the meaning of `'static`, I made the following test program:\r\n\r\n```rust\r\nfn foo<X:'static>(_x: X) { }\r\n\r\n#[cfg(not(acceptable))]\r\nfn bar() {\r\n    let a = 3;\r\n    let b = &a;\r\n    foo(b);\r\n}\r\n\r\n#[cfg(acceptable)]\r\nfn bar() {\r\n    static c : int = 4;;\r\n    let d : &'static int = &c;\r\n    foo(d);\r\n}\r\n\r\nfn main() {\r\n    bar();\r\n}\r\n```\r\n\r\nTranscript of compiling above program, illustrating that the `--cfg acceptable` variant of `bar` compiles successfully, showing that the`'static` kind bound only disallows non-`static` references, not *all* references:\r\n\r\n```\r\n% rustc --version\r\n/Users/fklock/opt/rust-dbg/bin/rustc 0.10-pre (caf17fe 2014-03-21 02:21:50 -0700)\r\nhost: x86_64-apple-darwin\r\n% rustc /tmp/s.rs\r\n/tmp/s.rs:7:5: 7:8 error: instantiating a type parameter with an incompatible type `&int`, which does not fulfill `'static`\r\n/tmp/s.rs:7     foo(b);\r\n                ^~~\r\nerror: aborting due to previous error\r\n% rustc --cfg acceptable /tmp/s.rs\r\n% ./s\r\n%\r\n```\r\n\r\n(Note that the explicit type annotation on `let d : &'static int` is necessary; it did not suffice for me to just write `let d = &'static c;`. That might be a latent bug, I am not sure yet.)\r\n\r\nAnyway, a fix to the documentation seemed prudent.","bors",true],["e06348ea5516eb18f1b33d3ca19e3f0867bdf6df","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13049 : alexcrichton/rust/io-fill, r=huonw\n\nThis method can be used to fill a byte slice of data entirely, and it's considered an error if any error happens before its entirely filled.","bors",true],["bcaaffbe1e1c6a6a3abdabdb4fdaef36358dae33","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13080 : alexcrichton/rust/possible-osx-deadlock, r=brson\n\nThe OSX bots have been deadlocking recently in the rustdoc tests. I have only\r\nbeen able to rarely reproduce the deadlock on my local setup. When reproduced,\r\nit looks like the child process is spinning on the malloc mutex, which I\r\npresume is locked with no other threads to unlock it.\r\n\r\nI'm not convinced that this is what's happening, because OSX should protect\r\nagainst this with pthread_atfork by default. Regardless, running as little code\r\nas possible in the child after fork() is normally a good idea anyway, so this\r\ncommit moves all allocation to the parent process to run before the child\r\nexecutes.\r\n\r\nAfter running 6k iterations of rustdoc tests, this deadlocked twice before, and\r\nafter 20k iterations afterwards, it never deadlocked. I draw the conclusion that\r\nthis is either sweeping the bug under the rug, or it did indeed fix the\r\nunderlying problem.","bors",true],["6bf3fca8ff90bbeff8d5c437aa784d0dbf8f9455","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #12900 : alexcrichton/rust/rewrite-sync, r=brson\n\n* Remove clone-ability from all primitives. All shared state will now come\r\n  from the usage of the primitives being shared, not the primitives being\r\n  inherently shareable. This allows for fewer allocations for stack-allocated\r\n  primitives.\r\n* Add `Mutex<T>` and `RWLock<T>` which are stack-allocated primitives for purely\r\n  wrapping a piece of data\r\n* Remove `RWArc<T>` in favor of `Arc<RWLock<T>>`\r\n* Remove `MutexArc<T>` in favor of `Arc<Mutex<T>>`\r\n* Shuffle around where things are located\r\n  * The `arc` module now only contains `Arc`\r\n  * A new `lock` module contains `Mutex`, `RWLock`, and `Barrier`\r\n  * A new `raw` module contains the primitive implementations of `Semaphore`,\r\n    `Mutex`, and `RWLock`\r\n* The Deref/DerefMut trait was implemented where appropriate\r\n* `CowArc` was removed, the functionality is now part of `Arc` and is tagged\r\n  with `#[experimental]`.\r\n* The crate now has #[deny(missing_doc)]\r\n* `Arc` now supports weak pointers\r\n\r\nThis is not a large-scale rewrite of the functionality contained within the\r\n`sync` crate, but rather a shuffling of who does what an a thinner hierarchy of\r\nownership to allow for better composability.","bors",true],["56cae9b3c0a49ff39f14570301db43008e810695","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","comm: Implement synchronous channels\n\nThis commit contains an implementation of synchronous, bounded channels for\nRust. This is an implementation of the proposal made last January [1]. These\nchannels are built on mutexes, and currently focus on a working implementation\nrather than speed. Receivers for sync channels have select() implemented for\nthem, but there is currently no implementation of select() for sync senders.\n\nRust will continue to provide both synchronous and asynchronous channels as part\nof the standard distribution, there is no intent to remove asynchronous\nchannels. This flavor of channels is meant to provide an alternative to\nasynchronous channels because like green tasks, asynchronous channels are not\nappropriate for all situations.\n\n[1] - https://mail.mozilla.org/pipermail/rust-dev/2014-January/007924.html","Alex Crichton",true]],"size":6,"ref":"refs/heads/sync-chan","head":"56cae9b3c0a49ff39f14570301db43008e810695"}