LLVM provides these functions as intrinsics, and will generate calls to
libc when appropriate. They are exposed in the `ptr` module as
`copy_nonoverlapping_memory`, `copy_memory` and `set_memory`.
@graydon: r?
r? @jld or @graydon
The calculation looks right to me, but perhaps one of you two can double check. You two seem like you are doing the most recent work in this sort of area.
LLVM provides these functions as intrinsics, and will generate calls to
libc when appropriate. They are exposed in the `ptr` module as
`copy_nonoverlapping_memory`, `copy_memory` and `set_memory`.
There is a pointer to #4760, which is a closed issue. The real issue is
the more general problem described in #4653. Correct the comment.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
I noticed this while reading the tutorial.
[1/2] adds tests to guard against regressions.
[2/2] corrects the tutorial.
Please let me know if you have a standard place to put tests: they seem to be all over the place currently.
There are two distinct kinds of bad-for-loops to check for with two
distinct error messages. The current bad-for-loop.rs does not make this
clear, so rewrite it into bad-for-loop{,-2}.rs. The two failing
prototypes are:
fn quux(_: &fn(&int) -> int) -> bool { true }
fn quux(_: &fn(&int) -> bool) -> () { }
Note that the second one runs fine in rust-0.6 (the latest release), and
only fails with a rust built from `incoming`.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Handle more characters that appear in types, most notably <>): were
missing. Also the new scheme takes care that no two different input
strings result in the same mangled string, which was not the case before.
Fixes#6921
Handle more characters that appear in types, most notably <>): were
missing. Also the new scheme takes care that no two different input
strings result in the same mangled string, which was not the case before.
Fixes#6921
