| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rearrange some code in rustpkg:
* Move command line argument parsing to parse_args.rs
* Introduce an enum to descibe commands such as Build, Install, and Clean.
* Move sysroot from Context to BuildContext, to make parse_args more modular.
This is my first pull request, so please tell me if there is anything I need to do.
|
|
|
|
simple-lib and deeply and c-dependencies still have problems.
But they were nt caused by this pull request
|
|
rustlib. Fixes #3319
|
|
|
|
|
|
|
|
|
|
|
|
This patch for #9543 throws an `obsolete syntax` error for `extern mod foo (name="bar")` .
I was wondering if [this](https://github.com/fhahn/rust/compare/mozilla:master...fhahn:issue9543-remove-extern-mod-foo?expand=1#diff-da9d34ca1d0f6beee2838cf02e07345cR4444) is the correct place to do this?
I think the wording of the error message could probably be improved as well.
If this approach is OK, I'm going to run the whole test suite tomorrow and update the old syntax to the new one.
|
|
|
|
|
|
It replaces `dummy_sp()`.
|
|
|
|
|
|
Issue #11048
|
|
|
|
|
|
|
|
|
|
|
|
* vec::raw::to_ptr is gone
* Pausible => Pausable
* Removing @
* Calling the main task "<main>"
* Removing unused imports
* Removing unused mut
* Bringing some libextra tests up to date
* Allowing compiletest to work at stage0
* Fixing the bootstrap-from-c rmake tests
* assert => rtassert in a few cases
* printing to stderr instead of stdout in fail!()
|
|
This prevents usage of the win32 utf-16 helper functions from outside of libstd.
Closes #9053
|
|
Closes #11035
|
|
Understand 'pkgid' in stage0. As a bonus, the snapshot now contains now metadata
(now that those changes have landed), and the snapshot download is half as large
as it used to be!
|
|
See commits for details.
|
|
raw}::copy_memory.
Slices carry their length with them, so we can just use that
information.
|
|
|
|
|
|
cadencemarseille/rust/issue-10754-std-run-unwrap-on-None, r=alexcrichton
The problem was that std::run::Process::new() was unwrap()ing the result
of std::io::process::Process::new(), which returns None in the case
where the io_error condition is raised to signal failure to start the
process.
Have std::run::Process::new() similarly return an Option\<run::Process\>
to reflect the fact that a subprocess might have failed to start. Update
utility functions run::process_status() and run::process_output() to
return Option\<ProcessExit\> and Option\<ProcessOutput\>, respectively.
Various parts of librustc and librustpkg needed to be updated to reflect
these API changes.
closes #10754
|
|
The problem was that std::run::Process::new() was unwrap()ing the result
of std::io::process::Process::new(), which returns None in the case
where the io_error condition is raised to signal failure to start the
process.
Have std::run::Process::new() similarly return an Option<run::Process>
to reflect the fact that a subprocess might have failed to start. Update
utility functions run::process_status() and run::process_output() to
return Option<ProcessExit> and Option<ProcessOutput>, respectively.
Various parts of librustc and librustpkg needed to be updated to reflect
these API changes.
closes #10754
|
|
rustpkg assumes library files to be in a directory called `lib`, but on Windows they are instead in the `bin` directory. This patch changes nothing on Unix system, since `libdir()` returns `"lib"` there.
|
|
This isn't super useful for libraries yet without #10593.
Fixes #7633.
|
|
When --dep-info is given, rustc will write out a `$input_base.d` file in the
output directory that contains Makefile compatible dependency information for
use with tools like make and ninja.
|
|
|
|
Also remove all instances of 'self within the codebase.
This fixes #10889.
|
|
34 uses of `Cell` remain.
r? @alexcrichton
|
|
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.
Fixes #10188, #8523.
|
|
cells.
|
|
|
|
This implements parts of the changes to `Result` and `Option` I proposed and discussed in this thread: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006254.html
This PR includes:
- Adding `ok()` and `err()` option adapters for both `Result` variants.
- Removing `get_ref`, `expect` and iterator constructors for `Result`, as they are reachable with the variant adapters.
- Removing `Result`s `ToStr` bound on the error type because of composability issues. (See https://mail.mozilla.org/pipermail/rust-dev/2013-November/006283.html)
- Some warning cleanups
|
|
In order to keep up to date with changes to the libraries that `llvm-config`
spits out, the dependencies to the LLVM are a dynamically generated rust file.
This file is now automatically updated whenever LLVM is updated to get kept
up-to-date.
At the same time, this cleans out some old cruft which isn't necessary in the
makefiles in terms of dependencies.
Closes #10745
Closes #10744
|
|
|
|
This reverts commit c54427ddfbbab41a39d14f2b1dc4f080cbc2d41b.
Leave the #[ignores] in that were added to rustpkg tests.
Conflicts:
src/librustc/driver/driver.rs
src/librustc/metadata/creader.rs
|
|
|
|
This function had type &[u8] -> ~str, i.e. it allocates a string
internally, even though the non-allocating version that take &[u8] ->
&str and ~[u8] -> ~str are all that is necessary in most circumstances.
|
|
|
|
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
|
|
|
|
|
