The path we pass to rustc will be visible in panic messages and
backtraces: they will be user visible!
Avoid junk in these paths by passing relative paths to rustc.
For most advanced users, `libcore` or `libstd` in the path will be
a clue to the location -- inside our code, not theirs.
Store both the relative path to the source as well as the absolute.
Use the relative path where it matters, compiling the main crates,
instead of changing all of the build process to cope with relative
paths.
Example output after this patch:
```
$ ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
$ RUST_BACKTRACE=1 ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
stack backtrace:
1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des
at ../src/libstd/sys/unix/backtrace.rs:158
2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw
at ../src/libstd/panicking.rs:58
3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw
at ../src/libstd/rt/unwind/mod.rs:273
4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw
at ../src/libstd/rt/unwind/mod.rs:212
5: 0x7ff59c1eced7 - rust_begin_unwind
6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B
at ../src/libcore/panicking.rs:64
7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B
at ../src/libcore/panicking.rs:45
8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829
9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa
10: 0x7ff59c1f1c18 - rust_try_inner
11: 0x7ff59c1f1c05 - rust_try
12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw
at ../src/libstd/rt/unwind/mod.rs:147
at ../src/libstd/rt/unwind/mod.rs:130
at ../src/libstd/rt/mod.rs:128
13: 0x7ff59c1e628e - main
14: 0x7ff59b3f6b44 - __libc_start_main
15: 0x7ff59c1e6078 - <unknown>
16: 0x0 - <unknown>
```
* Slate these features to be stable in 1.2 instead of 1.1 (not being backported)
* Have the `FromRawFd` implementations follow the contract of the `FromRawFd`
trait by taking ownership of the primitive specified.
* Refactor the implementations slightly to remove the `unreachable!` blocks as
well as separating the stdio representation of `std::process` from
`std::sys::process`.
cc #25494
… congruent due to rounding errors
@semarie this affected both openbsd and bitrig. it seems the correct solution is to switch to fixed point arithmetic in the timeout code, the same as freebsd.
Various methods in both libcore/char.rs and librustc_unicode/char.rs were previously marked with #[inline], now every method is marked in char's impl blocks.
Partially fixes#26124.
EDIT: I'm not familiar with pull reqests (yet), apparently Github added my second commit to thit PR...
Fixes#26124
Implement RFC rust-lang/rfcs#1123
Add str method str::split_at(mid: usize) -> (&str, &str).
Also a minor cleanup in the collections::str module. Remove redundant slicing of self.
As far as I was able to determine, it's currently *impossible* to allocate a C NUL-terminated string in Rust and then return it to C (transferring ownership), without leaking memory. There is support for passing the string to C (borrowing).
To complicate matters, it's not possible for the C code to just call `free` on the allocated string, due to the different allocators in use.
`CString` has no way to recreate itself from a pointer. This commit adds one. This is complicated a bit because Rust `Vec`s want the pointer, size, and capacity.
To deal with that, another method to shrink and "leak" the `CString` to a `char *` is also provided.
We can then use `strlen` to determine the length of the string, which must match the capacity.
**TODO**
- [x] Improve documentation
- [x] Add stability markers
- [x] Convert to `Box<[u8]>`
### Example code
With this example code:
```rust
#![feature(libc)]
#![feature(cstr_to_str)]
#![feature(c_str_memory)]
extern crate libc;
use std::ffi::{CStr,CString};
#[no_mangle]
pub extern fn reverse(s: *const libc::c_char) -> *const libc::c_char {
let s = unsafe { CStr::from_ptr(s) };
let s2 = s.to_str().unwrap();
let s3: String = s2.chars().rev().collect();
let s4 = CString::new(s3).unwrap();
s4.into_ptr()
}
#[no_mangle]
pub extern fn cleanup(s: *const libc::c_char) {
unsafe { CString::from_ptr(s) };
}
```
Compiled using `rustc --crate-type dylib str.rs`, I was able to link against it from C (`gcc -L. -l str str.c -o str`):
```c
#include <stdio.h>
extern char *reverse(char *);
extern void cleanup(char *);
int main() {
char *s = reverse("Hello, world!");
printf("%s\n", s);
cleanup(s);
}
```
As well as dynamically link via Ruby:
```ruby
require 'fiddle'
require 'fiddle/import'
module LibSum
extend Fiddle::Importer
dlload './libstr.dylib'
extern 'char* reverse(char *)'
extern 'void cleanup(char *)'
end
s = LibSum.reverse("hello, world!")
puts s
LibSum.cleanup(s)
```
Doc patch for #26120. Extra words here, because "value" is repeated.
I haven't read about whether/how it should go to stable (sorry), but I think it would help newcomers.
Thanks,
* Slate these features to be stable in 1.2 instead of 1.1 (not being backported)
* Have the `FromRawFd` implementations follow the contract of the `FromRawFd`
trait by taking ownership of the primitive specified.
* Refactor the implementations slightly to remove the `unreachable!` blocks as
well as separating the stdio representation of `std::process` from
`std::sys::process`.
The text claimed 'any borrow must last for a _smaller_ scope than the
owner', however the accurate way of describing the comparison is
inclusive (i.e., 'less than or equal to' vs. 'less than').
