auto merge of #9278 : alexcrichton/rust/ndebug, r=brson
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
Alex Crichton [Wed, 18 Sep 2013 04:02:11 +0000 (21:02 -0700)]
Invert --cfg debug to --cfg ndebug
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
auto merge of #9332 : eugals/rust/master, r=alexcrichton
It is intended to optimize/beautify the code generated in a few trivial trait operations.
Let's take the following code as an example:
```
trait Stuff {
fn bar(&self);
}
fn callBar(s: &Stuff) {
s.bar();
}
struct Foo;
impl Stuff for Foo {
fn bar(&self) {
}
}
pub fn main() {
let o = Foo;
callBar(&o as &Stuff);
}
```
Although this change doesn't increase the compilation speed much (I mentioned only about 1-2% boost on "rustc -O -Z time-passes syntax.rs"), but I still think it's a good thing to do as it greatly simplifies/clarifies LL generated in some cases which would definitely help in the future code generation investigations.
I don't provide any new test cases in this patch as it is merely an optimization.
Sorry guys, I somehow messed my previous PR and I don't see any better way to fix as to recreate it here.
auto merge of #9321 : chris-morgan/rust/lowercase-nan-methods, r=brson
This is for consistency in naming conventions.
- ``std::num::Float::NaN()`` is changed to ``nan()``;
- ``std::num::Float.is_NaN()`` is changed to ``is_nan()``; and
- ``std::num::strconv::NumStrConv::NaN()`` is changed to ``nan()``.
auto merge of #9320 : chris-morgan/rust/unreachable-macro-part-two-of-two-containing-the-destruction-of-the-unreachable-function, r=alexcrichton
This is the second of two parts of #8991, now possible as a new snapshot
has been made. (The first part implemented the unreachable!() macro; it
was #8992, 6b7b8f2682.)
``std::util::unreachable()`` is removed summarily; any code which used
it should now use the ``unreachable!()`` macro.
auto merge of #9308 : ben0x539/rust/lexer-error-spans, r=alexcrichton
Previously, the lexer calling `rdr.fatal(...)` would report the span of
the last complete token, instead of a span within the erroneous token
(besides one span fixed in 1ac90bb).
This branch adds wrappers around `rdr.fatal(...)` that sets the span
explicilty, so that all fatal errors in `libsyntax/parse/lexer.rs` now
report the offending code more precisely. A number of tests try to
verify that, though the `compile-fail` testing setup can only check that
the spans are on the right lines, and the "unterminated string/block
comment" errors can't have the line marked at all, so that's incomplete.
This closes #9149.
Also, the lexer errors now report the offending code in the error message,
not just via the span, just like other errors do.
auto merge of #9285 : sfackler/rust/future, r=alexcrichton
The `Drop` implementation was used to prevent `Future` from being implicitly copyable. Since `~fn`s are no longer copyable, this is no longer needed. I added a cfail test to make sure that this is actually the case.
I method-ized all of the `Future` creation methods and added a new one, `spawn_with`, which is similar to `task::spawn_with`.
Benjamin Herr [Thu, 19 Sep 2013 14:21:29 +0000 (16:21 +0200)]
lexer: report problematic chars verbatim or as escape sequence
... instead of giving their numeric codepoint, following the lead of fdaae34. So the error message for, say, '\_' mentions _ instead of 95,
and '\●' now mentions \u25cf.
Benjamin Herr [Thu, 19 Sep 2013 14:11:23 +0000 (16:11 +0200)]
lexer: show correct span on lexical errors
Previously, the lexer calling `rdr.fatal(...)` would report the span of
the last complete token, instead of a span within the erroneous token
(besides one span fixed in 1ac90bb).
This commit adds a wrapper around `rdr.fatal(...)` that sets the span
explicilty, so that all fatal errors in `libsyntax/parse/lexer.rs` now
report the offending code more precisely. A number of tests try to
verify that, though the `compile-fail` testing setup can only check that
the spans are on the right lines, and the "unterminated string/block
comment" errors can't have the line marked at all, so that's incomplete.
Chris Morgan [Thu, 19 Sep 2013 05:37:34 +0000 (15:37 +1000)]
Rename the NaN and is_NaN methods to lowercase.
This is for consistency in naming conventions.
- ``std::num::Float::NaN()`` is changed to ``nan()``;
- ``std::num::Float.is_NaN()`` is changed to ``is_nan()``; and
- ``std::num::strconv::NumStrConv::NaN()`` is changed to ``nan()``.
auto merge of #9280 : alexcrichton/rust/less-c++, r=brson
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).
Chris Morgan [Thu, 19 Sep 2013 05:04:03 +0000 (15:04 +1000)]
Replace unreachable() calls with unreachable!().
This is the second of two parts of #8991, now possible as a new snapshot
has been made. (The first part implemented the unreachable!() macro; it
was #8992, 6b7b8f2682.)
``std::util::unreachable()`` is removed summarily; any code which used
it should now use the ``unreachable!()`` macro.
Alex Crichton [Tue, 17 Sep 2013 21:45:50 +0000 (14:45 -0700)]
Remove rust_run_program.cpp
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).
auto merge of #9260 : alexcrichton/rust/libuv-processes, r=brson
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).
auto merge of #9263 : catamorphism/rust/rustpkg-issue-7879, r=brson
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.
Tim Chevalier [Tue, 17 Sep 2013 02:27:09 +0000 (19:27 -0700)]
rustpkg: Make crates, not packages, the unit of rustpkg dependencies
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.
Alex Crichton [Mon, 16 Sep 2013 22:28:56 +0000 (15:28 -0700)]
Implement process bindings to libuv
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.
auto merge of #9264 : ben0x539/rust/pp-work, r=alexcrichton
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.
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.
auto merge of #9269 : alexcrichton/rust/ignore-rustpkg-test, r=brson
@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.
Alex Crichton [Wed, 18 Sep 2013 00:11:15 +0000 (17:11 -0700)]
Ignore a test which is blocking a snapshot
@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.
auto merge of #9257 : alexcrichton/rust/better-address-insignificant, r=thestinger
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! ...
Benjamin Herr [Tue, 17 Sep 2013 20:13:47 +0000 (22:13 +0200)]
pp: also print bounds in paths with no generic params
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.
auto merge of #9235 : olsonjeffery/rust/newrt_file_io_1, r=thestinger
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!
Alex Crichton [Tue, 17 Sep 2013 18:24:05 +0000 (11:24 -0700)]
Prevent a rare linkage issue with an xcrate static
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! ...
auto merge of #9236 : steveklabnik/rust/rustpkg_init, r=catamorphism
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
auto merge of #9244 : thestinger/rust/drop, r=catamorphism
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.
projects / rust.git / log