This is done in two steps:
First, we make foreign functions not consider modes at all. This is because previously ++ mode was the only way to pass structs to foreign functions and so forth. We also add a lint mode warning if you use `&&` mode in a foreign function, since the semantics of that change (it used to pass a pointer to the C function, now it doesn't).
Then, we remove by value and make it equivalent to `+` mode. At the same time, we stop parsing `-` mode and convert all uses of it to `+` mode (it was already being parsed to `+` mode anyhow).
This obsoletes pull request #5298.
r? @brson
adjusting a few foreign functions that were declared with by-ref
mode. This also allows us to remove by-val mode in the near future.
With copy mode, though, we have to be careful because Rust will implicitly pass
somethings by pointer but this may not be the C ABI rules. For example, rust
will pass a struct Foo as a Foo*. So I added some code into the adapters to
fix this (though the C ABI rules may put the pointer back, oh well).
This patch also includes a lint mode for the use of by-ref mode
in foreign functions as the semantics of this have changed.
Continuing #5140
For the sake of getting this merged I've disabled debuginfo tests on mac (where running gdb needs root). Please feel free to follow up with further improvements.
r? @graydon
This removes `log` from the language. Because we can't quite implement it as a syntax extension (probably need globals at the least) it simply renames the keyword to `__log` and hides it behind macros.
After this the only way to log is with `debug!`, `info!`, etc. I figure that if there is demand for `log!` we can add it back later.
I am not sure that we ever agreed on this course of action, though I *think* there is consensus that `log` shouldn't be a statement.
The correct opendir/readdir to use appear to be the 64-bit versions called
opendir$INODE64, etc. but for some reason I can't get them to link properly
on i686. Putting them in librustrt and making gcc figure it out works.
This mystery will have to wait for another day.
The original change bit Servo because rust-harfbuzz includes libharfbuzz.a in its link_args. This works fine in the rust-harfbuzz subdirectory where the static library resides, but when this is propagated to servo_gfx, the lirbrary can no longer be found since it's a relative path.
This is the first in a series of patches I'm working on to clean up the code related to `deriving`. This patch allows
```
#[deriving_eq]
#[deriving_iter_bytes]
#[deriving_clone]
struct Foo { bar: uint }
```
to be replaced with:
```
#[deriving(Eq, IterBytes, Clone)]
struct Foo { bar: uint }
```
It leaves the old attributes alone for the time being.
Eventually I'd like to incorporate the new closest-match-suggestion infrastructure for mistyped trait names, and also pass the sub-attributes to the deriving code, so that the following will be possible:
```
#[deriving(TotalOrd(qux, bar))]
struct Foo { bar: uint, baz: char, qux: int }
```
This says to derive an `impl` in which the objects' `qux` fields are compared first, followed by `bar`, while `baz` is ignored in the comparison. If no fields are specified explicitly, all fields will be compared in the order they're defined in the `struct`. This might also be useful for `Eq`. Coming soon.
Currently the opts_present() function only checks to see if the option is
configured in the match, but doesn't actually check to see if the option
value has been set. This means that opt_present('h') may return false while
opts_present([~'h']) returns true.
Add a test case to catch this condition and fix opts_present() to check
the value before returning true.
Note, there is another API difference between these two functions that this
does not address. Currently if you pass a non-configured option to
opt_present() the program will fail!(), but opts_present() simply returns
false. If it is acceptable to standardize on the fail!() then opts_present()
should probably be implemented in terms of the opt_present() function.
The `local_stage0.sh` script was not updated after commit 7dcbaed renamed
librustsyntax to libsyntax.
Currently, `./configure --enable-local-rust --local-rust-root=FOO && make` will
fail due to the missing libsyntax; this change corrects this.
This will allow you to use the `+` operator to add together any two
Options, assuming that the contents of each Option likewise implement
`+`. So Some(4) + Some(1) == Some(5), and adding with None leaves the
other value unchanged.
This might be monoidic? I don't know what that word means!
The local_stage0 script was not updated after commit 7dcbaed renamed
librustsyntax to libsyntax, so builds using local Rust fail due to
missing libsyntax.
These changes make const translation use adjustments (autodereference, autoreference, bare-fn-to-closure), like normal code does, replacing some ad-hoc logic that wasn't always right.
As a convenient side-effect, explicit dereference (both of pointers and of newtypes) is also supported in const expressions.
There is also a “bonus fix” for a bug in the pretty-printer exposed by one of the added tests.
r?
Followup to #5022. This is the same, but everything is in `core::rt` now. `std::uv_ll` is moved to `core::unstable::uvll`, with the intent that it eventually move into its own crate (blocked on #5192 at least). I've had to disable the uv tests because of #2064. All of `core::rt` is disabled on platforms that aren't mac or linux until I complete the windows thread local storage bindings and ARM context switching.
My immediate next priorities will be to fix#2064 and clean up the uv bindings, get everything building on all platforms.
