debug_assert to ensure that from_raw_parts is only used properly aligned

[RalfJung]

This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by #42789 if there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently fail in the rg testsuite. So maybe it is worth it, after all.

I have seen the attribute #[rustc_inherit_overflow_checks] in some places, does that make it so that the caller's debug status is relevant? Is there a similar attribute for debug_assert!? That could even subsume rustc_inherit_overflow_checks: Something like rustc_inherit_debug_flag could affect all places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason not to handle the debug flag that way? I guess currently we apply debug flags like cfg so this is dropped early during the MIR pipeline?

EDIT: I learned from @eddyb that because of how debug_assert! works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^

[rust-highfive]

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

[RalfJung]

So just to be clear, this can probably not be merged right now because it fails the ripgrep test suite on Windows:

---- search_buffer::tests::invert_match_line_numbers stdout ----
thread 'search_buffer::tests::invert_match_line_numbers' panicked at 'attempt to create unaligned slice', libcore\slice\mod.rs:3881:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
---- search_buffer::tests::line_numbers stdout ----
thread 'search_buffer::tests::line_numbers' panicked at 'attempt to create unaligned slice', libcore\slice\mod.rs:3881:5
---- search_stream::tests::after_context_invert_one1 stdout ----
thread 'search_stream::tests::after_context_invert_one1' panicked at 'attempt to create unaligned slice', libcore\slice\mod.rs:3881:5
[...]

However, I was unable to reproduce this on Linux. Cc @BurntSushi

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:54:00] 
[00:54:00] running 102 tests
base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "codegen" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-5.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:54:04] 
[00:54:04] 
[00:54:04] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:54:04] Build completed unsuccessfully in 0:10:26
[00:54:04] Build completed unsuccessfully in 0:10:26
[00:54:04] make: *** [check] Error 1
[00:54:04] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:045c86b2
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:027d7810:start=1533206148803488733,finish=1533206148813202501,duration=9713768
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:20e02da4
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:025bfbc2
travis_time:start:025bfbc2
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:00649745
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[RalfJung]

Oh dang, we test codegen even with debug assertions and somehow this used to work but now it cannot optimize away these alignment tests?

This is basically the inverse problem of not having debug assertions in user builds -- with debug-assertions = true, even optimized codegen test builds get the assertion.

[BurntSushi]

@RalfJung Is there a way to get a full backtrace? I don't think I can do much with the given info. And this is only failing on Windows but not other platforms?

I'm trying to think where there might even be a from_raw_parts call in this code. The only one I can come up with is the one in bytecount, which ripgrep uses to count lines.

I can't immediately spot the error by inspection, but I can try to debug this later.

cc @llogiq @Veedrac

[RalfJung]

@RalfJung Is there a way to get a full backtrace? I don't think I can do much with the given info. And this is only failing on Windows but not other platforms?

I'd love to have a backtrace.^^ But CI doesn't give us one and indeed I have been unable to reproduce.

The only one I can come up with is the one in bytecount, which ripgrep uses to count lines.

So Chunk has alignment > 1 I assume?

from_raw_parts is testing against mem::align_of, but bytecount looks at mem::size_of, could that be a problem?

[RalfJung]

Regarding the codegen issue, I got it to optimize better by adding some assume but now the codegen tests fail because the assume is still there... as in

; Function Attrs: nounwind uwtable
define void @vec_clear(%"alloc::vec::Vec<u32>"* noalias nocapture dereferenceable(24) %x) unnamed_addr #0 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* @rust_eh_personality {
start:
  %0 = getelementptr inbounds %"alloc::vec::Vec<u32>", %"alloc::vec::Vec<u32>"* %x, i64 0, i32 3
  %1 = getelementptr inbounds %"alloc::vec::Vec<u32>", %"alloc::vec::Vec<u32>"* %x, i64 0, i32 0, i64 0
  %2 = load i64, i64* %1, align 8, !range !0, !alias.scope !1
  %3 = and i64 %2, 3
  %4 = icmp eq i64 %3, 0
  tail call void @llvm.assume(i1 %4) #2, !noalias !10
  store i64 0, i64* %0, align 8, !alias.scope !11, !noalias !12
  ret void
}

which has a test saying "there must not be a load or an icmp"...

[BurntSushi]

@RalfJung It looks like the only implementations of ByteChunk are usize, u8x16 and u8x32, which means Chunk never has an alignment of 1.

[RalfJung]

It looks like the only implementations of ByteChunk are usize, u8x16 and u8x32, which means Chunk never has an alignment of 1.

Also all of these have size be a multiple of align, so the code should be correct.

I am a little surprised by the (align - offset_ptr) % align, isn't offset_ptr < align and hence the modulo strictly a NOP?
But I cannot see any logic error in that code either.

[Veedrac]

The return value in my code can be misaligned if the slice is length-0. I'd assumed that was OK.

[RalfJung]

Ah, you mean if the inner Chunk part is empty? Yeah, good point.

Now I wonder if align_to does that correct.

[RalfJung]

Okay, align_to is correct. I pushed a testcase to this PR.

[RalfJung]

I proposed a fix for bytecount at llogiq/bytecount#42

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:57:25] failures:
[00:57:25] 
[00:57:25] ---- [codegen] codegen/vec-clear.rs stdout ----
[00:57:25] 
[00:57:25] error: verification with 'FileCheck' failed
[00:57:25] status: exit code: 1
[00:57:25] command: "/usr/lib/llvm-5.0/bin/FileCheck" "--input-file" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll" "/checkout/src/test/codegen/vec-clear.rs"
[00:57:25] ------------------------------------------
[00:57:25] 
[00:57:25] ------------------------------------------
[00:57:25] stderr:
[00:57:25] stderr:
[00:57:25] ------------------------------------------
[00:57:25] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll:18:7: error: CHECK-NOT: string occurred!
[00:57:25]  %1 = load i64, i64* %0, align 8, !range !0, !alias.scope !1
[00:57:25]       ^
[00:57:25] /checkout/src/test/codegen/vec-clear.rs:18:16: note: CHECK-NOT: pattern specified here
[00:57:25]  // CHECK-NOT: load
[00:57:25] 
[00:57:25] ------------------------------------------
[00:57:25] 
[00:57:25] thread '[codegen] codegen/vec-clear.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3149:9
---
[00:57:25] test result: FAILED. 74 passed; 1 failed; 27 ignored; 0 measured; 0 filtered out
[00:57:25] 
[00:57:25] 
[00:57:25] 
[00:57:25] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/codegen" "--build-

The command "date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
" exited with 0.
travis_fold:start:after_failure.1

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[RalfJung]

llogiq/bytecount#42 has been merged. What has to happen for the Rust test suite to pick it up when testing ripgrep?

[llogiq]

We need a new ripgrep release that picks up the new version. Then someone needs to upgrade ripgrep.

I'll send a ripgrep PR.

[gnzlbg]

This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions.

Once re-compiling std becomes easier, this will help more, so don't be let down by this, I think adding debug_assert!s to std is great.

[RalfJung]

I updated the ripgrep commit fetched by cargotest. Is anything else needed for updates like this?

Also, there still is the problem with the codegen tests. It seems wrong to expect codegen tests to still pass when libstd has debug assertions turned on. What is the best way to ignore some/call codegen tests when debug-assertions = true?

[gnzlbg]

We probably want to have a way to disable certain tests when the debug assertions are enabled, by, for example, just adding:

// ignore-debug-assertions-on

or similar. I don't think compiletest (https://github.com/rust-lang/rust/tree/master/src/tools/compiletest) supports this, but maybe that logic could be added somewhere around here:

rust/src/tools/compiletest/src/header.rs

Line 600 in c63bb1d

fn parse_cfg_name_directive(&self, line: &str, prefix: &str) -> bool {

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:48:46] ....................................................................................................
[00:48:49] ....................................................................................................
[00:48:51] ....................................................................................................
[00:48:54] ....................................................................................................
[00:48:57] iiiiiiiii...........................................................................................
[00:49:03] ....................................................................................................
[00:49:06] .....i..............................................................................................
[00:49:09] ..............i.....................................................................................
[00:49:12] ....................................................................................................
---
[00:56:48] failures:
[00:56:48] 
[00:56:48] ---- [codegen] codegen/vec-clear.rs stdout ----
[00:56:48] 
[00:56:48] error: verification with 'FileCheck' failed
[00:56:48] status: exit code: 1
[00:56:48] command: "/usr/lib/llvm-5.0/bin/FileCheck" "--input-file" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll" "/checkout/src/test/codegen/vec-clear.rs"
[00:56:48] ------------------------------------------
[00:56:48] 
[00:56:48] ------------------------------------------
[00:56:48] stderr:
[00:56:48] stderr:
[00:56:48] ------------------------------------------
[00:56:48] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll:18:7: error: CHECK-NOT: string occurred!
[00:56:48]  %1 = load i64, i64* %0, align 8, !range !0, !alias.scope !1
[00:56:48]       ^
[00:56:48] /checkout/src/test/codegen/vec-clear.rs:18:16: note: CHECK-NOT: pattern specified here
[00:56:48]  // CHECK-NOT: load
[00:56:48] 
[00:56:48] ------------------------------------------
[00:56:48] 
[00:56:48] thread '[codegen] codegen/vec-clear.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3149:9
---
travis_time:end:22ba34bc:start=1533560768355127014,finish=1533560768361217674,duration=6090660
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:22c51257
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0e306760
travis_time:start:0e306760
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:380f8505
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[RalfJung]

@kennytm informs me that all CI runners have debug assertions enabled, except for the ones building the release artifacts with do not run tests. (So we don't test the actual thing we are shipping? oO)

So, // ignore-debug would effectively completely ignore the test. That doesn't work. The only options I can think of are:

• Postpone this until libstd is easily built in multiple "profiles".
• Run codegen tests on the dist jobs, and use the // ignore-debug approach.
• Change at least one non-dist job to have assertions disabled, and use the // ignore-debug approach.

[alexcrichton]

@bors: r+

[bors]

📌 Commit 1001b2b has been approved by alexcrichton

[bors]

⌛️ Testing commit 1001b2b with merge 580ca3e...

[bors]

💔 Test failed - status-travis

[rust-highfive]

The job dist-i686-apple of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:22]       Memory: 8 GB
[00:04:22]       Boot ROM Version: VMW71.00V.0.B64.1704110547
[00:04:22]       Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
[00:04:22]       SMC Version (system): 2.8f0
[00:04:22]       Serial Number (system): VMU8+kN8sKpS
[00:04:22] 
[00:04:22] hw.ncpu: 4
[00:04:22] hw.byteorder: 1234
[00:04:22] hw.memsize: 8589934592
---
[01:04:54] thread 'main' panicked at 'failed to download openssl source: exit code: 6', bootstrap/native.rs:602:17
[01:04:54] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:04:54] failed to run: /Users/travis/build/rust-lang/rust/build/bootstrap/debug/bootstrap build
[01:04:54] Build completed unsuccessfully in 0:59:11
[01:04:54] make: *** [all] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:011d4452
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_fold:start:after_failure.2
travis_time:start:213ee864
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
total 0
drwx------+ 15 travis  staff  510 Jan 25  2018 ..
drwx------   2 travis  staff   68 Dec  6  2017 .
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:00195140
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
travis_time:end:00195140:start=1534666833430916000,finish=1534666833453234000,duration=22318000
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0c5e0068
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:2615c2e8
travis_time:start:2615c2e8
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:08b059ee
$ dmesg | grep -i kill
$ dmesg | grep -i kill
Unable to obtain kernel buffer: Operation not permitted
usage: sudo dmesg
travis_fold:end:after_failure.6

Done. Your build exited with 1.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[kennytm]

@bors retry #40474

I guess this is not 9696 since it is a macOS...

[01:04:54] Copying stage2 rustc from stage1 (i686-apple-darwin -> i686-apple-darwin / i686-apple-darwin)
[01:04:54]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[01:04:54]                                  Dload  Upload   Total   Spent    Left  Speed
[01:04:54] 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: s3-us-west-1.amazonaws.com
[01:04:54]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[01:04:54]                                  Dload  Upload   Total   Spent    Left  Speed
[01:04:54] 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: s3-us-west-1.amazonaws.com
[01:04:54]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[01:04:54]                                  Dload  Upload   Total   Spent    Left  Speed
[01:04:54] 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: s3-us-west-1.amazonaws.com
[01:04:54] thread 'main' panicked at 'failed to download openssl source: exit code: 6', bootstrap/native.rs:602:17
[01:04:54] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:04:54] failed to run: /Users/travis/build/rust-lang/rust/build/bootstrap/debug/bootstrap build
[01:04:54] Build completed unsuccessfully in 0:59:11
[01:04:54] make: *** [all] Error 1

[bors]

⌛️ Testing commit 1001b2b with merge 8928de7...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 8928de7 to master...

[rust-highfive]

📣 Toolstate changed by #52972!

Tested on commit 8928de7.
Direct link to PR: #52972

💔 book on windows: test-pass → test-fail (cc @carols10cents @steveklabnik, @rust-lang/infra).
💔 book on linux: test-pass → test-fail (cc @carols10cents @steveklabnik, @rust-lang/infra).

[kennytm]

[00:52:30] ---- /checkout/src/doc/book/2018-edition/src/ch19-01-unsafe-rust.md - _::Unsafe_Rust::Calling_an_Unsafe_Function_or_Method::Creating_a_Safe_Abstraction_over_Unsafe_Code (line 335) stdout ----
[00:52:30] thread '/checkout/src/doc/book/2018-edition/src/ch19-01-unsafe-rust.md - _::Unsafe_Rust::Calling_an_Unsafe_Function_or_Method::Creating_a_Safe_Abstraction_over_Unsafe_Code (line 335)' panicked at 'test executable failed:
[00:52:30] 
[00:52:30] thread 'main' panicked at 'attempt to create unaligned slice', libcore/slice/mod.rs:3897:5
[00:52:30] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[00:52:30] 
[00:52:30] ', librustdoc/test.rs:368:17
[00:52:30] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[00:52:30] 
[00:52:30] 
[00:52:30] failures:
[00:52:30]     /checkout/src/doc/book/2018-edition/src/ch19-01-unsafe-rust.md - _::Unsafe_Rust::Calling_an_Unsafe_Function_or_Method::Creating_a_Safe_Abstraction_over_Unsafe_Code (line 335)
[00:52:30] 
[00:52:30] test result: FAILED. 11 passed; 1 failed; 1 ignored; 0 measured; 0 filtered out

This line:

https://github.com/rust-lang/book/blame/88cdde350fd3a90c93f3bac8b4f168f105d28060/2018-edition/src/ch19-01-unsafe-rust.md#L338

(the same error affects the second edition as well)

(We also need to update nomicon to remove #![feature(unique)] BTW)

[RalfJung]

(We also need to update nomicon to remove #![feature(unique)] BTW)

The nomicon is already fixed, but not updated in rustc yet.

[RalfJung]

Submitted rust-lang/book#1492