Change:
--> $DIR/manual_memcpy.rs:94:14 | LL |     for i in from..from + src.len() { <del> |              ^^^^^^^^^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[from..from + src.len()].clone_from_slice(&src[0..(from + src.len() - from)])` </del> <ins> |              ^^^^^^^^^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[from..from + src.len()].clone_from_slice(&src[..(from + src.len() - from)])` </ins> error: it looks like you're manually copying between slices --> $DIR/manual_memcpy.rs:98:14 | LL |     for i in from..from + 3 { <del> |              ^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[from..from + 3].clone_from_slice(&src[0..(from + 3 - from)])` </del> <ins> |              ^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[from..from + 3].clone_from_slice(&src[..(from + 3 - from)])` </ins> error: it looks like you're manually copying between slices <del> --> $DIR/manual_memcpy.rs:105:14 </del> <ins> --> $DIR/manual_memcpy.rs:110:14 </ins> | LL |     for i in 0..src.len() { |              ^^^^^^^^^^^^ help: try replacing the loop by: `dst[..src.len()].clone_from_slice(&src[..])`

Discussion:
I ran into an issue in where was getting expanded into instead of , which resulted in a compile error. We should add some tests that make sure we can still compile code after macros have been expanded.
To clarify: if I understand you correctly, you're saying that the expansion of error!("...") was being rendered by pprust as log(1,"..."), not that the expansion was actually incorrect. Is that correct? First off, that would obviously be a bug in the pretty-printer, which should be fixed. The larger issue of making sure that pretty-printed code compiles I would nominate for well-covered.
Yep, that was the problem, it's fixed now though. The larger issue still stands.
just a bug, removing milestone/nomination.
Fixed by !
Yay!

When using and together, the compiler complains that is an unused import even when a call to something like exists. Removing gets rid of the warning and the crate compiles. However, the crate will fail to link (for example with ) unless the is there. It seems like the warning is a bug unless the intent is to have also bring in foo itself. Here's a small crate that shows the example. This was originally found in rust-core-foundation.
Looking at the code, that's a genuinely unused import when not compiling with . I ran into this when removing unused imports in the compiler, and you can prefix the import with so that the import is only resolved when testing. Other options I've seen are to have a which is 'd off, or just put the in the function itself.
You're right. In this case I moved the inside the test function.

The macro is required, as is that exact order of the bounds, and the use of the repeated bound in the . (It's not specific to though.) output:
Works now, I'll check in a test case
Test case checked in in . Closing

The following code... ...results in the following error: Both and are loans of , so it should be safe to update to new loan of as updating doesn't cause to be freed.
This works now; I'll check in the test case.
Test case checked in in . Closing

So, after much wrangling with MinGW to get Rust to compile on my Windows partition, I'm trying to get Rust-SDL to work. When compiling it, and then running the demo application, I get the following, somewhat esoteric message: The procedure entry point ZN4bool14extensions9meth80572eq154e94be02e19a92306E could not be located in the dynamic link library core-- Is this a configuration issue? A bug? Me being silly?
I'm suspecting this is a dup of
Well, that puts my mind to rest! Thanks

<prefn main() { #error("%?", x);*/ } </preyields