Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
Because less C++ is better C++!
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
This is a re-landing of #8645, except that the bindings are *not* being used to
power std::run just yet. Instead, this adds the bindings as standalone bindings
inside the rt::io::process module.
I made one major change from before, having to do with how pipes are
created/bound. It's much clearer now when you can read/write to a pipe, as
there's an explicit difference (different types) between an unbound and a bound
pipe. The process configuration now takes unbound pipes (and consumes ownership
of them), and will return corresponding pipe structures back if spawning is
successful (otherwise everything is destroyed normally).
r? @brson Treating a package as the thing that can have other packages depend on it,
and depends on other packages, was wrong if a package has more than one
crate. Now, rustpkg knows about dependencies between crates in the same
package. This solves the problem reported in #7879 where rustpkg wrongly
discovered a circular dependency between thhe package and itself, and
recursed infinitely.
Closes#7879
Treating a package as the thing that can have other packages depend on it,
and depends on other packages, was wrong if a package has more than one
crate. Now, rustpkg knows about dependencies between crates in the same
package. This solves the problem reported in #7879 where rustpkg wrongly
discovered a circular dependency between thhe package and itself, and
recursed infinitely.
Closes#7879
This is a re-landing of #8645, except that the bindings are *not* being used to
power std::run just yet. Instead, this adds the bindings as standalone bindings
inside the rt::io::process module.
I made one major change from before, having to do with how pipes are
created/bound. It's much clearer now when you can read/write to a pipe, as
there's an explicit difference (different types) between an unbound and a bound
pipe. The process configuration now takes unbound pipes (and consumes ownership
of them), and will return corresponding pipe structures back if spawning is
successful (otherwise everything is destroyed normally).
This patch fixes some errors of MIPS target, however, MIPS C ABI is still broken. I will send another PR to fix the problem.
Because MIPS target has no "generic" CPU name, I add --target-cpu and --target-feature to RUST_FLAGS. In order to workaround the "compact frame descriptions incompatible with DWARF2 .eh_frame" problem, the linker I used is CXX but not CC.
std: Remove {float,f64,f32}::from_str in favor of from_str in the prelude
Like issue #9209, remove float::{from_str, from_str_radix} in favor of
the two corresponding traits. The same for modules f64 and f32.
New usage is:
from_str::<float>("1.2e34")
Look like this now
```
-Z FLAG Set internal debugging options
-v --version Print version info and exit
Additional help:
-W help Print 'lint' options and default settings
-Z help Print internal options for debugging rustc
```
Since 3b6314c the pretty printer seems to only print trait bounds for `ast::ty_path(...)`s that have a generics arguments list. That seems wrong, so let's always print them.
Closes#9253, un-xfails test for #7673.
This commit adds support for `\0` escapes in character and string literals.
Since `\0` is equivalent to `\x00`, this is a direct translation to the latter
escape sequence. Future builds will be able to compile using `\0` directly.
Also updated the grammar specification and added a test for NUL characters.
Like issue #9209, remove float::{from_str, from_str_radix} in favor of
the two corresponding traits. The same for modules f64 and f32.
New usage is
from_str::<float>("1.2e34")
@catamorphism says he has a fix coming soon, so I didn't allocate an issue for
it. If it festers for more than a few days I'll open something up though.
@catamorphism says he has a fix coming soon, so I didn't allocate an issue for
it. If it festers for more than a few days I'll open something up though.
If a static is flagged as address_insignificant, then for LLVM to actually
perform the relevant optimization it must have an internal linkage type. What
this means, though, is that the static will not be available to other crates.
Hence, if you have a generic function with an inner static, it will fail to link
when built as a library because other crates will attempt to use the inner
static externally.
This gets around the issue by inlining the static into the metadata. The same
relevant optimization is then applied separately in the external crate. What
this ends up meaning is that all statics tagged with #[address_insignificant]
will appear at most once per crate (by value), but they could appear in multiple
crates.
This should be the last blocker for using format! ...
Since 3b6314c3 the pretty printer seems to only print trait bounds for
`ast::ty_path(...)`s that have a generics arguments list. That seems
wrong, so let's always print them.
Closes#9253, un-xfails test for #7673.
A quick rundown:
- added `file::{readdir, stat, mkdir, rmdir}`
- Added access-constrained versions of `FileStream`; `FileReader` and `FileWriter` respectively
- big rework in `uv::file` .. most actions are by-val-self methods on `FsRequest`; `FileDescriptor` has gone the way of the dinosaurs
- playing nice w/ homing IO (I just copied ecr's work, hehe), etc
- added `FileInfo` trait, with an impl for `Path`
- wrapper for file-specific actions, with the file path always implied by self's value
- has the means to create `FileReader` & `FileWriter` (this isn't exposed in the top-level free function API)
- has "safe" wrappers for `stat()` that won't throw in the event of non-existence/error (in this case, I mean `is_file` and `exists`)
- actions should fail if done on non-regular-files, as appropriate
- added `DirectoryInfo` trait, with an impl for `Path`
- pretty much ditto above, but for directories
- added `readdir` (!!) to iterate over entries in a dir as a `~[Path]` (this was *brutal* to get working)
...<del>and lots of other stuff</del>not really. Do your worst!
If a static is flagged as address_insignificant, then for LLVM to actually
perform the relevant optimization it must have an internal linkage type. What
this means, though, is that the static will not be available to other crates.
Hence, if you have a generic function with an inner static, it will fail to link
when built as a library because other crates will attempt to use the inner
static externally.
This gets around the issue by inlining the static into the metadata. The same
relevant optimization is then applied separately in the external crate. What
this ends up meaning is that all statics tagged with #[address_insignificant]
will appear at most once per crate (by value), but they could appear in multiple
crates.
This should be the last blocker for using format! ...
Closes#9045
Built on top of #9235, which isn't strictly needed for now, but I imagine I will use part of. Unsure.
I mostly wanted to start this off to get some feedback from @catamorphism and others. These are the directories that actually need made, but I was thinking about adding a few other things:
1. an `examples` directory, since it seems like that's a common pattern
2. a `.gitignore` file that ignores `build`. And anything else that makes sense
3. a sample module that'd actually compile
Feedback?
This constrains the span to the appropriate argument, so you know which
one caused the problem. Instead of
foo.rs:2:4: 2:21 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~~~~~~~~~~~~~~~
it will say
foo.rs:2:14 2:17 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~
This doesn't close any bugs as the goal is to convert the parameter to by-value, but this is a step towards being able to make guarantees about `&T` pointers (where T is Freeze) to LLVM.
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
Note that some `rustdoc_ng` tests were removed, but @cmr says they weren't supposed to be there in the first place. The rustdoc_ng code should also be included in `make install` and `make dist` now.
First shot at a new tutorial for rustpkg. /cc @catamorphism
Right now, I'm linking to my sample package on GitHub, I'm not sure that everyone would be comfortable with me having that there. Maybe under the mozilla org? I think having one to install and hold up as a default makes sense.
Closes#9221.
"rustpkg test" isn't implemented yet, so it shouldn't be in the manpage. Referring interested parties to the manual is probably
the right thing for now; eventually, these documents should merge.
/cc @catamorphism
