GitHub PushEvent at 2014-04-19 19:58:19
Repository: rust
Actor: lifthrasiir
Payload: {"shas":[["30ff17f809869dec37d7b501fb532dc88fd47832","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","Upgrade LLVM\n\nThis comes with a number of fixes to be compatible with upstream LLVM:\n\n* Previously all monomorphizations of \"mem::size_of()\" would receive the same\n  symbol. In the past LLVM would silently rename duplicated symbols, but it\n  appears to now be dropping the duplicate symbols and functions now. The symbol\n  names of monomorphized functions are now no longer solely based on the type of\n  the function, but rather the type and the unique hash for the\n  monomorphization.\n\n* Split stacks are no longer a global feature controlled by a flag in LLVM.\n  Instead, they are opt-in on a per-function basis through a function attribute.\n  The rust #[no_split_stack] attribute will disable this, otherwise all\n  functions have #[split_stack] attached to them.\n\n* The compare and swap instruction now takes two atomic orderings, one for the\n  successful case and one for the failure case. LLVM internally has an\n  implementation of calculating the appropriate failure ordering given a\n  particular success ordering (previously only a success ordering was\n  specified), and I copied that into the intrinsic translation so the failure\n  ordering isn't supplied on a source level for now.\n\n* Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions,\n  etc.","Alex Crichton",true],["32a81d1e161a8b4a498c88ddb79955775d18fbfd","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","configure: Enable libc++ with LLVM with clang\n\nWhen clang is enabled, also pass through --enable-libcpp to LLVM's configure\ncommand line to help it pick up the most recent c++ runtime library. This also\nchanges the mklldeps.py script to pick up on whether LLVM was linked against\nstdc++ or c++ based on the --cxxflags that llvm-config prints.\n\nIn an ongoing attempt to update LLVM, the bots need to update their C compilers\nto something that supports c++11 (LLVM recently switched). The OSX bots are\nrunning Lion (10.7), which only supports up to gcc 4.2 and clang 3.2. Apparently\nthe libstdc++ is too old (even on the most updated command line tools) for LLVM,\nbut using libc++ instead appears to work just fine.","Alex Crichton",true],["682c401045fbc24ecec8cab0e315293192825c69","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","configure: Enable clang for older OSX gcc versions\n\nOSX often has a more recent version of clang than it does for GCC. When an older\nversion of gcc is detected on OSX, the --enable-clang flag is implicitly\nenabled.","Alex Crichton",true],["36d5635273f7759b9aedce04bc8b111edb9c0742","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","etc: The --system-libs flag is LLVM 3.5+\n\nOlder version of LLVM did not have this flag, so we need to fall back to our\nprevious library detection when using older versions of LLVM.","Alex Crichton",true],["acdee8b904178e13616cea8c31bcdb1f063ddef5","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","llvm: Add an option to statically link libstdc++\n\nThe goal of the snapshot bots is to produce binaries which can run in as many\nlocations as possible. Currently we build on Centos 6 for this reason, but with\nLLVM's update to C++11, this reduces the number of platforms that we could\npossibly run on.\n\nThis adds a --enable-llvm-static-stdcpp option to the ./configure script for\nRust which will enable building a librustc with a static dependence on\nlibstdc++. This normally isn't necessary, but this option can be used on the\nsnapshot builders in order to continue to make binaries which should be able to\nrun in as many locations as possible.","Alex Crichton",true],["ad3de7fdb58cb2beb06780794006b4184807c75e","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","rustc: Hint to the linker about static/shared libs\n\nIf a linker finds both a static and a dynamic version of the same library, then\nthe linker often chooses the dynamic version. This is surprising when a native\nlibrary is specified as being \"static\" in rust source. This modifies the linker\ncommand line to obey the hints given in rust source files and instructing the\nlinker to prefer a particular version of a found library.\n\nUnfortunately, this patch has no effect on osx because the linker supports\nno such hint, and it also has no effect on windows because the linker apparently\njust ignores it. For now this is predominately used to enable the previous patch\nof linking to libstdc++ statically, but more support would need to be added for\nthis in the future if we wanted to officially support it.\n\ncc #12557 (doesn't close because it doesn't support OSX and windows)","Alex Crichton",true],["58ae1e7c625491e9eceebdc9120ff009361106fa","a4334599ca34b527c4da3bd7c32bb40d15c24c00@gmail.com","Remove rule that is confusing\n\nThe original text stated that one should only return a unique or managed pointer if you were given one in the first place. This makes it sound as if the function *should* return a unique pointer if it were given a unique pointer. The rest of the section goes on to describe why this is bad, and the example of bad code does exactly what the rule just said to do.\r\n\r\nI reworded the original rule into a reference to the more concise rule mentioned at the bottom of the section, which helps add emphasis (a la 'it bears repeating').","Brandon Waskiewicz",true],["ce2bab68d69ee04e17c0165dbdb7b583d5a7c991","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13585 : brandonw/rust/patch-1, r=cmr\n\nThe original text stated that one should only return a unique or managed pointer if you were given one in the first place. This makes it sound as if the function *should* return a unique pointer if it were given a unique pointer. The rest of the section goes on to describe why this is bad, and the example of bad code does exactly what the rule just said to do.\r\n\r\nI reworded the original rule into a reference to the more concise rule mentioned at the bottom of the section, which helps add emphasis (a la 'it bears repeating').","bors",true],["7d3b0bf3912fabf52fdd6926900e578e55af1b49","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","std: Make ~[T] no longer a growable vector\n\nThis removes all resizability support for ~[T] vectors in preparation of DST.\nThe only growable vector remaining is Vec<T>. In summary, the following methods\nfrom ~[T] and various functions were removed. Each method/function has an\nequivalent on the Vec type in std::vec unless otherwise stated.\n\n* slice::OwnedCloneableVector\n* slice::OwnedEqVector\n* slice::append\n* slice::append_one\n* slice::build (no replacement)\n* slice::bytes::push_bytes\n* slice::from_elem\n* slice::from_fn\n* slice::with_capacity\n* ~[T].capacity()\n* ~[T].clear()\n* ~[T].dedup()\n* ~[T].extend()\n* ~[T].grow()\n* ~[T].grow_fn()\n* ~[T].grow_set()\n* ~[T].insert()\n* ~[T].pop()\n* ~[T].push()\n* ~[T].push_all()\n* ~[T].push_all_move()\n* ~[T].remove()\n* ~[T].reserve()\n* ~[T].reserve_additional()\n* ~[T].reserve_exect()\n* ~[T].retain()\n* ~[T].set_len()\n* ~[T].shift()\n* ~[T].shrink_to_fit()\n* ~[T].swap_remove()\n* ~[T].truncate()\n* ~[T].unshift()\n* ~str.clear()\n* ~str.set_len()\n* ~str.truncate()\n\nNote that no other API changes were made. Existing apis that took or returned\n~[T] continue to do so.\n\n[breaking-change]","Alex Crichton",true],["c318d72b8651e40559c40455475f730cf5f07a1f","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","std: Fail more gracefully on thread spawn errors\n\nOn windows, correctly check for errors when spawning threads, and on both\nwindows and unix handle the error more gracefully rather than printing an opaque\nassertion failure.\n\nCloses #13589","Alex Crichton",true],["675b82657e7d9fd4c824ff3c6dbead1edd1ab515","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","Update the rest of the compiler with ~[T] changes","Alex Crichton",true],["59f3414a4a66a132648bd89ae697924304715bd3","a4334599ca34b527c4da3bd7c32bb40d15c24c00@gmail.com","Add another case where cindent is correct\n\nWhen calling a function, or anything with nested parens,\ndefault to cindent's indent. The least error-prone way I\ncould think of identifying this is to look for a line\nthat ends with a ',', as well as a non-zero number of\nany character except parens before the comma, and\nthen an open paren.\n\nThis will overlap with the previous rule accounting for\nfunction definitions, but that should be fine because\nit is also using cindent.","Brandon Waskiewicz",true],["d1d8497e53af86687e701eea0fe2a41b0c4313eb","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13588 : alexcrichton/rust/no-more-growing, r=thestinger\n\nThis is all in preparation for DST. This removes all the growable/shrinkable methods from `~[T]`.","bors",true],["065c4a69676d74bb9fbe726719e36fb0673517da","34fa6c8662a152b3dbe01e09fd67f1cb8cea280d@gmail.com","Add git to README.md dependency list because configure requires it","mdinger",true],["c44c7abb42df8f13efdaa8b871893ad1dd5941e4","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13601 : mdinger/rust/readme, r=brson\n\nConfigure required git be installed so this should be added to the dependencies list.  If it's only required when using git, a note could also be added.","bors",true],["b75683cadf6c4c55360202cd6a0106be80532451","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13600 : brandonw/rust/master, r=brson\n\nWhen calling a function, or anything with nested parens,\r\ndefault to cindent's indent. The least error-prone way I\r\ncould think of identifying this is to look for a line\r\nthat ends with a ',', as well as a non-zero number of\r\nany character except parens before the comma, and\r\nthen an open paren.\r\n\r\nThis will overlap with the previous rule accounting for\r\nfunction definitions, but that should be fine because\r\nit is also using cindent.","bors",true],["031212bfd9aadd5e77fef0f5b48ad0d6c81ad6d5","dddccf71ac082961ac856a6ac9f2b87a0ba13044@gmail.com","Fix smallest-hello-world.rs interaction with `puts`\n\nIt now hands `puts` a zero-terminated string, like it expects.\n\nFix #13603.","Tobias Bucher",true],["426d701f8bbd22aa22fefb69d71eaa7dc8bbe170","60c6d277a8bd81de7fdde19201bf9c58a3df08f4@alexcrichton.com","debuginfo: Clamp the maximum dwarf version to 3\n\nThis is a consequence of #13611 and our bots running a \"fairly old\" gdb which\ndoesn't understand the newer versions of dwarf.","Alex Crichton",true],["3ec9f05534993635b7562381331713cfa1184900","e468f80cecb9247776b439ed161d31bbccdcf9df@psych0tik.net","vim: Add StrBuf as type to hilighting","Richo Healey",true],["9b7cfd3c724bbad9dd8a0115bb2619f307b73f8c","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #13513 : alexcrichton/rust/up-llvm, r=brson\n\nThis is a bit of an interesting upgrade to LLVM. Upstream LLVM has started using C++11 features, so they require a C++11 compiler to build. I've updated all the bots to have a C++11 compiler, and they appear to be building LLVM successfully:\r\n\r\n* Linux bots - I added gcc/g++ 4.7 (good enough)\r\n* Android bots - same as the linux ones\r\n* Mac bots - I installed the most recent command line tools for Lion which gives us clang 3.2, but LLVM wouldn't build unless it was explicitly asked to link to `libc++` instead of `libstdc++`. This involved tweaking `mklldeps.py` and the `configure` script to get things to work out\r\n* Windows bots - mingw-w64 has gcc 4.8.1 which is sufficient for building LLVM (hurray!)\r\n* BSD bots - I updated FreeBSD to 10.0 which brought with it a relevant version of clang.\r\n\r\nThe largest fallout I've seen so far is that the test suite doesn't work at all on FreeBSD 10. We've already stopped gating on FreeBSD due to #13427 (we used to be on freebsd 9), so I don't think this puts us in too bad of a situation. I will continue to attempt to fix FreeBSD and the breakage on there.\r\n\r\nThe LLVM update brings with it all of the recently upstreamed LLVM patches. We only have one local patch now which is just an optimization, and isn't required to use upstream LLVM. I want to maintain compatibility with LLVM 3.3 and 3.4 while we can, and this upgrade is keeping us up to date with the 3.5 release. Once 3.5 is release we will in theory no longer require a bundled LLVM.","bors",true]],"size":33,"ref":"refs/heads/master","head":"3db2b6933d33d9a27bfd82e6de083d4aebe75a3b"}