- 01 7月, 2015 1 次提交
-
-
由 Ariel Ben-Yehuda 提交于
Fixes #26636
-
- 29 6月, 2015 13 次提交
-
-
由 bors 提交于
- Successful merges: #26593, #26644, #26645 - Failed merges:
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
I keep forgetting the command to do partial stage1 compile, so I think it would be helpful to add it into `make tips`.
-
由 Manish Goregaokar 提交于
Part of #24407. cc @michaelsproul
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Richo Healey 提交于
-
由 Peter Elmers 提交于
-
由 bors 提交于
This branch begins the work of unifying our type checking contexts into a single piece of state. The goal is to eventually have a single context that we can pass around instead of the fractured situation we currently have. There are still several things that must be done before beginning to make tables item local: - [ ] move FulfillmentContext into InferCtxt - [ ] modify SelectionContext to only take a single context argument - [ ] remove remaining typer impls - [ ] remove the ClosureTyper + Typer trait - [ ] do some renaming to make these things more applicable to their new roles r? @nikomatsakis As a side note there are a couple oddities that are temporary refactors that will be quickly cleaned up in a follow-up PR. cc @EddyB @Aatch @arielb1 @nrc
-
由 bors 提交于
Setting append without write doesn't give you a writeable file. Showing it as an example in the docs is confusing at best ([reddit](https://www.reddit.com/r/rust/comments/3bbz8w/why_is_writing_a_file_not_working_for_me/)) Using truncate (O_TRUNC) on a read-only file is an error on POSIX systems ("unspecified"). Note however that using create (O_CREAT) with read-only flags is fine. Related: #26103 (which IMHO is wrong; saying "append is different than write" when should simply be "append needs write". My vote is to make append imply write)
-
由 Remi Rampin 提交于
Setting append without write doesn't give you a writeable file. Showing it as an example in the docs is confusing at best. Using truncate on a read-only file is an error on POSIX systems (note however that using create with read-only flags is fine).
-
由 Jared Roesch 提交于
-
- 28 6月, 2015 13 次提交
-
-
由 bors 提交于
I've attempted to lurk these into a few PRs since they're tiny, but those PR's haven't landed so here they are. r? @steveklabnik
-
由 bors 提交于
This series of commits (currently rebased on https://github.com/rust-lang/rust/pull/26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP. This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library. The major components of this PR are: * Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit. * All APIs not available on Windows are now accessed through our dynamic-detection mechanism * Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
-
由 Jared Roesch 提交于
-
由 Alex Crichton 提交于
This commit enables executables linked against the standard library to run on Windows XP. There are two main components of this commit: * APIs not available on XP are shimmed to have a fallback implementation and use runtime detection to determine if they are available. * Mutexes on Windows were reimplemented to use critical sections on XP where rwlocks are not available. The APIs which are not available on XP are: * SetFileInformationByHandle - this is just used by `File::truncate` and that function just returns an error now. * SetThreadStackGuarantee - this is used by the stack overflow support on windows, but if this isn't available then it's just ignored (it seems non-critical). * All condition variable APIs are missing - the shims added for these apis simply always panic for now. We may eventually provide a fallback implementation, but for now the standard library does not rely on condition variables for normal use. * RWLocks, like condition variables, are missing entirely. The same story for condition variables is taken here. These APIs are all now panicking stubs as the standard library doesn't rely on RWLocks for normal use. Currently, as an optimization, we use SRWLOCKs for the standard `sync::Mutex` implementation on Windows, which is indeed required for normal operation of the standard library. To allow the standard library to run on XP, this commit reimplements mutexes on Windows to use SRWLOCK instances *if available* and otherwise a CriticalSection is used (with some checking for recursive locking). With all these changes put together, a 32-bit MSVC-built executable can run on Windows XP and print "hello world" Closes #12842 Closes #19992 Closes #24776
-
由 Richo Healey 提交于
-
由 Richo Healey 提交于
-
由 Jared Roesch 提交于
-
由 Jared Roesch 提交于
-
由 Jared Roesch 提交于
This first patch starts by moving around pieces of state related to type checking. The goal is to slowly unify the type checking state into a single typing context. This initial patch moves the ParameterEnvironment into the InferCtxt and moves shared tables from Inherited and ty::ctxt into their own struct Tables. This is the foundational work to refactoring the type checker to enable future evolution of the language and tooling.
-
由 Alex Crichton 提交于
It turns out that the 32-bit toolchain for MSVC has many of these functions as `static inline` functions in header files so there's not actually a symbol for Rust to call. All of the implementations just cast floats to their 64-bit variants and then cast back to 32-bit at the end, so the standard library now takes this strategy.
-
由 Alex Crichton 提交于
This commit adds the i686-pc-windows-msvc triple to the compiler's repertoire of triples to prepare for targeting 32-bit MSVC.
-
由 Alex Crichton 提交于
This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
-
- 27 6月, 2015 13 次提交
-
-
由 bors 提交于
- Successful merges: #26565, #26584, #26596, #26603 - Failed merges:
-
由 Tshepang Lekhonkhobe 提交于
Should have happened in 69abc12b
-
由 bors 提交于
These will first be deprecated in 1.2.0, not 1.1.0.
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
At the moment, it only mentions the fix to parallel codegen. I was going to add more, but I have to go for a while - If this isn't reviewed when I get back, I'll remove it and resubmit it after filling in more :)
-
由 Manish Goregaokar 提交于
Quick poll of basically the entire core team says this is ok.
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Fix #26537.
-
由 Manish Goregaokar 提交于
This is just a simple change to ignore KDevelop 4 (and pre-release versions of KDevelop 5) project files.
-
由 bors 提交于
Next step towards split local/global type contexts, after #26351. cc @rust-lang/compiler @jroesch
-
由 bors 提交于
Now that LLVM has been updated, the only remaining roadblock to implementing unwinding for MSVC is to fill out the runtime support in `std::rt::unwind::seh`. This commit does precisely that, fixing up some other bits and pieces along the way: * The `seh` unwinding module now uses `RaiseException` to initiate a panic. * The `rust_try.ll` file was rewritten for MSVC (as it's quite different) and is located at `rust_try_msvc_64.ll`, only included on MSVC builds for now. * The personality function for all landing pads generated by LLVM is hard-wired to `__C_specific_handler` instead of the standard `rust_eh_personality` lang item. This is required to get LLVM to emit SEH unwinding information instead of DWARF unwinding information. This also means that on MSVC the `rust_eh_personality` function is entirely unused (but is defined as it's a lang item). More details about how panicking works on SEH can be found in the `rust_try_msvc_64.ll` or `seh.rs` files, but I'm always open to adding more comments! A key aspect of this PR is missing, however, which is that **unwinding is still turned off by default for MSVC**. There is a [bug in llvm][llvm-bug] which causes optimizations to inline enough landing pads that LLVM chokes. If the compiler is optimized at `-O1` (where inlining isn't enabled) then it can bootstrap with unwinding enabled, but when optimized at `-O2` (inlining is enabled) then it hits a fatal LLVM error. [llvm-bug]: https://llvm.org/bugs/show_bug.cgi?id=23884
-
由 bors 提交于
My bad!
-
由 Cruz Julian Bishop 提交于
-