- 04 12月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
-
- 01 12月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
-
- 30 11月, 2013 2 次提交
-
-
由 Alex Crichton 提交于
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
-
由 Patrick Walton 提交于
-
- 29 11月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
-
- 27 11月, 2013 2 次提交
-
-
由 Patrick Walton 提交于
-
由 Patrick Walton 提交于
and librustpkg.
-
- 25 11月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
The reasons for doing this are: * The model on which linked failure is based is inherently complex * The implementation is also very complex, and there are few remaining who fully understand the implementation * There are existing race conditions in the core context switching function of the scheduler, and possibly others. * It's unclear whether this model of linked failure maps well to a 1:1 threading model Linked failure is often a desired aspect of tasks, but we would like to take a much more conservative approach in re-implementing linked failure if at all. Closes #8674 Closes #8318 Closes #8863
-
- 19 11月, 2013 1 次提交
-
-
由 Patrick Walton 提交于
-
- 12 11月, 2013 2 次提交
-
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
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
-
- 09 11月, 2013 2 次提交
-
-
由 Niko Matsakis 提交于
-
由 Andrei Formiga 提交于
-
- 03 11月, 2013 1 次提交
-
-
由 Chris Morgan 提交于
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.
-
- 01 11月, 2013 1 次提交
-
-
由 Brian Anderson 提交于
-
- 29 10月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
These methods are all excellent candidates for default methods, so there's no need to require extra imports of various traits.
-
- 25 10月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
Big fish fried here: extra::json most of the compiler extra::io_util removed extra::fileinput removed Fish left to fry extra::ebml
-
- 24 10月, 2013 1 次提交
-
-
由 Daniel Micay 提交于
-
- 22 10月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
Who doesn't like a massive renaming?
-
- 20 10月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
This commit resumes management of the stack boundaries and limits when switching between tasks. This additionally leverages the __morestack function to run code on "stack overflow". The current behavior is to abort the process, but this is probably not the best behavior in the long term (for deails, see the comment I wrote up in the stack exhaustion routine).
-
- 16 10月, 2013 2 次提交
-
-
由 Kevin Ballard 提交于
Add a new trait BytesContainer that is implemented for both byte vectors and strings. Convert Path::from_vec and ::from_str to one function, Path::new(). Remove all the _str-suffixed mutation methods (push, join, with_*, set_*) and modify the non-suffixed versions to use BytesContainer.
-
由 Kevin Ballard 提交于
Remove the old path. Rename path2 to path. Update all clients for the new path. Also make some miscellaneous changes to the Path APIs to help the adoption process.
-
- 09 10月, 2013 1 次提交
-
-
由 Daniel Micay 提交于
-
- 06 10月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
A few features are now hidden behind various #[feature(...)] directives. These include struct-like enum variants, glob imports, and macro_rules! invocations. Closes #9304 Closes #9305 Closes #9306 Closes #9331
-
- 05 10月, 2013 1 次提交
-
-
由 blake2-ppc 提交于
Avoid allocating extra copies of strings by using "" instead of ~"" for the debug options list and for the `time` function. This is a small change, but it is in a path that's always executed.
-
- 04 10月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
This adds a large doc-block to the top of the std::logging module explaining how to use it. This is mostly just making sure that all the information in the manual's section about logging is also here (in case someone decides to look into this module first). This also removes the old console_{on,off} methods. As far as I can tell, the functions were only used by the compiler, and there's no reason for them to be used because they're all turned off by default anyway (maybe they were turned on by default at some point...) I believe that this is the final nail in the coffin and closes #5021
-
- 01 10月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
-
- 27 9月, 2013 2 次提交
-
-
由 Brian Anderson 提交于
-
由 Alex Crichton 提交于
-
- 25 9月, 2013 1 次提交
-
-
由 Brian Anderson 提交于
This can cause unexpected errors in the runtime when done while scheduler threads are still initializing. Required some restructuring of the main_args functions in our libraries.
-
- 24 9月, 2013 2 次提交
-
-
由 Patrick Walton 提交于
-
由 Patrick Walton 提交于
-
- 22 9月, 2013 1 次提交
-
-
由 Brian Anderson 提交于
-
- 19 9月, 2013 1 次提交
-
-
由 Marvin Löbel 提交于
Some minor api and doc adjustments
-
- 18 9月, 2013 1 次提交
-
-
由 Brian Anderson 提交于
-
- 17 9月, 2013 1 次提交
-
-
由 Daniel Micay 提交于
-
- 10 9月, 2013 1 次提交
-
-
由 Niko Matsakis 提交于
has a unique id. Fixes numerous bugs in macro expansion and deriving. Add two representative tests. Fixes #7971 Fixes #6304 Fixes #8367 Fixes #8754 Fixes #8852 Fixes #2543 Fixes #7654
-
- 05 9月, 2013 1 次提交
-
-
由 Florian Hahn 提交于
-
- 01 9月, 2013 1 次提交
-
-
由 Marvin Löbel 提交于
-
- 27 8月, 2013 1 次提交
-
-
由 Alex Crichton 提交于
Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
-