https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.3.0 2015-08-03T04:15:01+00:00 2015-08-03T04:15:01+00:00 Vadim Chugunov vadimcn@gmail.com 2015-08-03T04:15:01+00:00 urn:sha1:96d1db2b1a43a149a1d0436a03a72aa01a39efd2 2015-07-30T18:35:16+00:00 Vadim Chugunov vadimcn@gmail.com 2015-07-14T01:11:44+00:00 urn:sha1:6112b220782134c70516301f7dab2e05e3283f54 2015-07-29T05:12:33+00:00 bors bors@rust-lang.org 2015-07-29T05:12:33+00:00 urn:sha1:4b4119d5c082e02f34b8ffb9aff41c8a71f30a13 These aren't really used for anything any more, so there doesn't seem to be much reason to leave them around in the `rt` directory. There was some limiting of threads spawned or tests when run under valgrind, but very little is run under valgrind nowadays so there's also no real use keeping these around. 2015-07-27T23:21:15+00:00 Alex Crichton alex@alexcrichton.com 2015-07-27T23:10:59+00:00 urn:sha1:cf1ff56f3c8a7a55fa38bcdda3907147d25382a2 These aren't really used for anything any more, so there doesn't seem to be much reason to leave them around in the `rt` directory. There was some limiting of threads spawned or tests when run under valgrind, but very little is run under valgrind nowadays so there's also no real use keeping these around. 2015-07-27T10:31:48+00:00 Eduard Burtescu edy.burt@gmail.com 2015-07-27T10:31:48+00:00 urn:sha1:5720f7055ac13cf616eb3a9a0b187440b56817d5 2015-07-24T00:03:04+00:00 Eli Friedman eli.friedman@gmail.com 2015-06-25T21:48:36+00:00 urn:sha1:6fa17b43d351ed4f9093cf80f4044d1208044241 Makes the lint a bit more accurate, and improves the quality of the diagnostic messages by explicitly returning an error message. The new lint is also a little more aggressive: specifically, it now rejects tuples, and it recurses into function pointers. 2015-07-22T09:13:09+00:00 bors bors@rust-lang.org 2015-07-22T09:13:09+00:00 urn:sha1:25281b121ff809f35a6abd7d2d115995436c3319 This commit moves the IR files in the distribution, rust_try.ll, rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main distribution. There's a few reasons for this change: * LLVM changes its IR syntax from time to time, so it's very difficult to have these files build across many LLVM versions simultaneously. We'll likely want to retain this ability for quite some time into the future. * The implementation of these files is closely tied to the compiler and runtime itself, so it makes sense to fold it into a location which can do more platform-specific checks for various implementation details (such as MSVC 32 vs 64-bit). * This removes LLVM as a build-time dependency of the standard library. This may end up becoming very useful if we move towards building the standard library with Cargo. In the immediate future, however, this commit should restore compatibility with LLVM 3.5 and 3.6. 2015-07-21T23:08:11+00:00 Alex Crichton alex@alexcrichton.com 2015-07-20T20:27:38+00:00 urn:sha1:c35b2bd226736925961ca6853b2ef29e8094cd90 This commit moves the IR files in the distribution, rust_try.ll, rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main distribution. There's a few reasons for this change: * LLVM changes its IR syntax from time to time, so it's very difficult to have these files build across many LLVM versions simultaneously. We'll likely want to retain this ability for quite some time into the future. * The implementation of these files is closely tied to the compiler and runtime itself, so it makes sense to fold it into a location which can do more platform-specific checks for various implementation details (such as MSVC 32 vs 64-bit). * This removes LLVM as a build-time dependency of the standard library. This may end up becoming very useful if we move towards building the standard library with Cargo. In the immediate future, however, this commit should restore compatibility with LLVM 3.5 and 3.6. 2015-07-21T16:18:30+00:00 Alex Crichton alex@alexcrichton.com 2015-07-16T18:59:53+00:00 urn:sha1:d68b152c3e2feb6ee18bdf2c992098376dbb528c This can fail on linux for various reasons, such as the /proc filesystem not being mounted. There are already many cases where we can't set up stack guards, so just don't worry about this case and communicate that no guard was enabled. I've confirmed that this allows the compiler to run in a chroot without /proc mounted. Closes #22642 2015-07-06T19:49:16+00:00 bors bors@rust-lang.org 2015-07-06T19:49:16+00:00 urn:sha1:2ceaa77ae26f38b599b5ab09ee925632ad613e1b This PR was originally going to be a "let's start running tests on MSVC" PR, but it didn't quite get to that point. It instead gets us ~80% of the way there! The steps taken in this PR are: * Landing pads are turned on by default for 64-bit MSVC. The LLVM support is "good enough" with the caveat the destructor glue is now marked noinline. This was recommended [on the associated bug](https://llvm.org/bugs/show_bug.cgi?id=23884) as a stopgap until LLVM has a better representation for exception handling in MSVC. The consequence of this is that MSVC will have a bit of a perf hit, but there are possible routes we can take if this workaround sticks around for too long. * The linker (`link.exe`) is now looked up in the Windows Registry if it's not otherwise available in the environment. This improves using the compiler outside of a VS shell (e.g. in a MSYS shell or in a vanilla cmd.exe shell). This also makes cross compiles via Cargo "just work" when crossing between 32 and 64 bit! * TLS destructors were fixed to start running on MSVC (they previously weren't running at all) * A few assorted `run-pass` tests were fixed. * The dependency on the `rust_builtin` library was removed entirely for MSVC to try to prevent any `cl.exe` compiled objects get into the standard library. This should help us later remove any dependence on the CRT by the standard library. * I re-added `rust_try_msvc_32.ll` for 32-bit MSVC and ensured that landing pads were turned off by default there as well. Despite landing pads being enabled, there are still *many* failing tests on MSVC. The two major classes I've identified so far are: * Spurious aborts. It appears that when optimizations are enabled that landing pads aren't always lined up properly, and sometimes an exception being thrown can't find the catch block down the stack, causing the program to abort. I've been working to reduce this test case but haven't been met with great success just yet. * Parallel codegen does not work on MSVC. Our current strategy is to take the N object files emitted by the N codegen threads and use `ld -r` to assemble them into *one* object file. The MSVC linker, however, does not have this ability, and this will need to be rearchitected to work on MSVC. I will fix parallel codegen in a future PR, and I'll also be watching LLVM closely to see if the aborts... disappear!