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.
Although in the example function `each` works as expected with
rust-0.6 (the latest release), it fails to even compile with `incoming`
rust (see test/compile-fail/bad-for-loop-2.rs). Change the function to
return a `bool` instead of `()`: this works fine with both versions of
rust, and does not misguide potential contributors.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
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
I'm close to flipping the switch on hygiene for let-bound identifiers. This commit adds a bunch of support functions for that change... but also a huge amount of cleanup in syntax.rc. The most interesting of these are
- the use of TLS for the interners everywhere. We had already breached the "no-global-state" dam by using TLS for encoding, and it saves a lot of code just to use it everywhere.
Also, there were many places where two or more interners were passed in attached to different structures, and the danger of having those diverge seemed greater that the danger of having a single one get big and heavy. If the interner size proves to be a problem, it should be quite simple to add a "parameterize"-like dynamic binding form--because we don't have interesting continuation operations (or tail calling, mostly) this should just be a case of a mutation followed by another later mutation. Again, this is only if the interner gets too big.
- I renamed the "repr" field of the identifier to "name". I can see the case for "repr" when there's only one field in the structure, but that's no longer the case; there's now a name and a context (both are uints).
- the interner now just maps between strings and uints, rather than between idents and uints. The former state made perfect sense when identifiers didn't have syntax contexts, but that's no longer the case.
I've run this patch against a fairly recent incoming, and it appears to pass all tests. Let's see if it can be merged....
Write a conservative .mailmap as an example for contributors to write
their preferred names/ email addresses to. This patch makes no
assumptions about the same author using different email addresses, and
only collects cases where the full-name of the person is spelt
differently for the same email address. Verify with:
$ git shortlog -se | cut -f 2 | cut -d\< -f 2 | sort | uniq -d
It only assumes that the author prefers the full-name that appears
dominantly, by number of contributions.
For the purposes of merging, a strictly alphabetical ordering is
advised. See MAPPING AUTHORS section of git-shortlog(1) to understand
the format of this file.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
