rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2013-11-30	Test fixes and merge conflicts	Alex Crichton	-0/+1

2013-11-29	Add generation of static libraries to rustc	Alex Crichton	-10/+4
	This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-28	Register new snapshots	Alex Crichton	-3/+1

2013-11-26	Remove unused std::routine	Alex Crichton	-1/+0

2013-11-19	add an initial `Gc<T>` stub with the API	Daniel Micay	-0/+1

2013-11-11	Move std::rt::io to std::io	Alex Crichton	-2/+4

2013-11-11	Remove #[fixed_stack_segment] and #[rust_stack]	Alex Crichton	-0/+2
	These two attributes are no longer useful now that Rust has decided to leave segmented stacks behind. It is assumed that the rust task's stack is always large enough to make an FFI call (due to the stack being very large). There's always the case of stack overflow, however, to consider. This does not change the behavior of stack overflow in Rust. This is still normally triggered by the __morestack function and aborts the whole process. C stack overflow will continue to corrupt the stack, however (as it did before this commit as well). The future improvement of a guard page at the end of every rust stack is still unimplemented and is intended to be the mechanism through which we attempt to detect C stack overflow. Closes #8822 Closes #10155
2013-11-08	Specify package_id for rust libs, to avoid spurious warnings	Andrei Formiga	-0/+1

2013-11-07	Edited comment for docs to show std::io is deleted and replaced by std::rt::io	Carol Willing	-1/+1

2013-11-03	Rename files to match current recommendations.	Chris Morgan	-0/+230
	New standards have arisen in recent months, mostly for the use of rustpkg, but the main Rust codebase has not been altered to match these new specifications. This changeset rectifies most of these issues. - Renamed the crate source files `src/libX/X.rs` to `lib.rs`, for consistency with current styles; this affects extra, rustc, rustdoc, rustpkg, rustuv, std, syntax. - Renamed `X/X.rs` to `X/mod.rs,` as is now recommended style, for `std::num` and `std::terminfo`. - Shifted `src/libstd/str/ascii.rs` out of the otherwise unused `str` directory, to be consistent with its import path of `std::ascii`; libstd is flat at present so it's more appropriate thus. While this removes some `#[path = "..."]` directives, it does not remove all of them, and leaves certain other inconsistencies, such as `std::u8` et al. which are actually stored in `src/libstd/num/` (one subdirectory down). No quorum has been reached on this issue, so I felt it best to leave them all alone at present. #9208 deals with the possibility of making libstd more hierarchical (such as changing the crate to match the current filesystem structure, which would make the module path `std::num::u8`). There is one thing remaining in which this repository is not rustpkg-compliant: rustpkg would have `src/std/` et al. rather than `src/libstd/` et al. I have not endeavoured to change that at this point as it would guarantee prompt bitrot and confusion. A change of that magnitude needs to be discussed first.