debug_assert to ensure that from_raw_parts is only used properly aligned #52972

RalfJung · 2018-08-02T09:40:17Z

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 · 2018-08-02T09:40:21Z

r? @shepmaster

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

RalfJung · 2018-08-02T09:42:56Z

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 · 2018-08-02T10:35:52Z

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 · 2018-08-02T10:46:45Z

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 · 2018-08-02T10:58:23Z

@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 · 2018-08-02T11:04:09Z

@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 · 2018-08-02T11:06:11Z

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 · 2018-08-02T11:07:05Z

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

RalfJung · 2018-08-02T11:59:16Z

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 · 2018-08-02T12:09:54Z

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

RalfJung · 2018-08-02T14:24:23Z

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

Now I wonder if align_to does that correct.

RalfJung · 2018-08-02T14:52:20Z

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

RalfJung · 2018-08-02T15:39:40Z

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

rust-highfive · 2018-08-02T16:34:04Z

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 · 2018-08-04T07:52:01Z

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

llogiq · 2018-08-04T08:15:19Z

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 · 2018-08-06T08:41:05Z

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 · 2018-08-06T12:07:38Z

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 · 2018-08-06T12:26:36Z

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 · 2018-08-06T13:06:11Z

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 · 2018-08-06T15:43:29Z

@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 · 2018-08-19T05:20:30Z

@bors: r+

bors · 2018-08-19T05:20:31Z

📌 Commit 1001b2b has been approved by alexcrichton

bors · 2018-08-19T07:10:29Z

⌛ Testing commit 1001b2b with merge 580ca3e50ef75f129ad5b138e37a1ed3024a8c21...

bors · 2018-08-19T08:22:10Z

💔 Test failed - status-travis

rust-highfive · 2018-08-19T08:22:11Z

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 · 2018-08-19T08:27:08Z

@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 · 2018-08-19T09:40:48Z

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

@eddyb

debug_assert to ensure that from_raw_parts is only used properly aligned 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](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). 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.^^

bors · 2018-08-19T12:21:50Z

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

rust-highfive · 2018-08-19T12:23:09Z

📣 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).

@carols10cents

Tested on commit rust-lang/rust@8928de7. Direct link to PR: <rust-lang/rust#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 · 2018-08-19T12:53:13Z

[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 · 2018-08-19T14:19:56Z

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

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

RalfJung · 2018-08-19T16:11:40Z

Submitted rust-lang/book#1492

…r=alexcrichton Add a debug_assert to Vec::set_len Following the precedent of rust-lang#52972, which found llogiq/bytecount#42. (This may well make a test fail; let's see what Travis says.)

debug_assert to ensure that from_raw_parts is only used properly aligned

7b24d2b

rust-highfive assigned shepmaster Aug 2, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 2, 2018

test that align_of handles alignment properly for the mid part

6fb97a6

RalfJung force-pushed the from_raw_parts_align branch from 21b76b7 to 6fb97a6 Compare August 2, 2018 15:32

RalfJung mentioned this pull request Aug 2, 2018

Make sure we do not create an unaligned slice llogiq/bytecount#42

Merged

llogiq mentioned this pull request Aug 6, 2018

update bytecount dependency BurntSushi/ripgrep#1003

Merged

RalfJung added 2 commits August 6, 2018 18:27

update ripgrep tested by cargotest

f47d56a

inore some codegen tests when debug assertions are enabled

1001b2b

rust-highfive assigned alexcrichton Aug 18, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 19, 2018

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 19, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 19, 2018

bors merged commit 1001b2b into rust-lang:master Aug 19, 2018

RalfJung mentioned this pull request Aug 19, 2018

fix UB in from_raw_parts_mut example rust-lang/book#1492

Merged

RalfJung mentioned this pull request Aug 31, 2018

Add debug assertions to raw pointer methods testing for unaligned/NULL pointers #53871

Closed

RalfJung deleted the from_raw_parts_align branch September 1, 2018 09:07

RalfJung mentioned this pull request Oct 8, 2018

Check alignment of raw pointers in debug mode #54915

Closed

scottmcm mentioned this pull request Jan 14, 2019

Add a debug_assert to Vec::set_len #57589

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

debug_assert to ensure that from_raw_parts is only used properly aligned #52972

debug_assert to ensure that from_raw_parts is only used properly aligned #52972

RalfJung commented Aug 2, 2018 •

edited

Loading

rust-highfive commented Aug 2, 2018

RalfJung commented Aug 2, 2018

rust-highfive commented Aug 2, 2018

RalfJung commented Aug 2, 2018 •

edited

Loading

BurntSushi commented Aug 2, 2018

RalfJung commented Aug 2, 2018

RalfJung commented Aug 2, 2018

BurntSushi commented Aug 2, 2018

RalfJung commented Aug 2, 2018

Veedrac commented Aug 2, 2018 •

edited

Loading

RalfJung commented Aug 2, 2018

RalfJung commented Aug 2, 2018

RalfJung commented Aug 2, 2018

rust-highfive commented Aug 2, 2018

RalfJung commented Aug 4, 2018

llogiq commented Aug 4, 2018

gnzlbg commented Aug 6, 2018

RalfJung commented Aug 6, 2018

gnzlbg commented Aug 6, 2018

rust-highfive commented Aug 6, 2018

RalfJung commented Aug 6, 2018

alexcrichton commented Aug 19, 2018

bors commented Aug 19, 2018

bors commented Aug 19, 2018

bors commented Aug 19, 2018

rust-highfive commented Aug 19, 2018

kennytm commented Aug 19, 2018

bors commented Aug 19, 2018

bors commented Aug 19, 2018

rust-highfive commented Aug 19, 2018

kennytm commented Aug 19, 2018

RalfJung commented Aug 19, 2018

RalfJung commented Aug 19, 2018

debug_assert to ensure that from_raw_parts is only used properly aligned #52972

debug_assert to ensure that from_raw_parts is only used properly aligned #52972

Conversation

RalfJung commented Aug 2, 2018 • edited Loading

rust-highfive commented Aug 2, 2018

RalfJung commented Aug 2, 2018

rust-highfive commented Aug 2, 2018

RalfJung commented Aug 2, 2018 • edited Loading

BurntSushi commented Aug 2, 2018

RalfJung commented Aug 2, 2018

RalfJung commented Aug 2, 2018

BurntSushi commented Aug 2, 2018

RalfJung commented Aug 2, 2018

Veedrac commented Aug 2, 2018 • edited Loading

RalfJung commented Aug 2, 2018

RalfJung commented Aug 2, 2018

RalfJung commented Aug 2, 2018

rust-highfive commented Aug 2, 2018

RalfJung commented Aug 4, 2018

llogiq commented Aug 4, 2018

gnzlbg commented Aug 6, 2018

RalfJung commented Aug 6, 2018

gnzlbg commented Aug 6, 2018

rust-highfive commented Aug 6, 2018

RalfJung commented Aug 6, 2018

alexcrichton commented Aug 19, 2018

bors commented Aug 19, 2018

bors commented Aug 19, 2018

bors commented Aug 19, 2018

rust-highfive commented Aug 19, 2018

kennytm commented Aug 19, 2018

bors commented Aug 19, 2018

bors commented Aug 19, 2018

rust-highfive commented Aug 19, 2018

kennytm commented Aug 19, 2018

RalfJung commented Aug 19, 2018

RalfJung commented Aug 19, 2018

RalfJung commented Aug 2, 2018 •

edited

Loading

RalfJung commented Aug 2, 2018 •

edited

Loading

Veedrac commented Aug 2, 2018 •

edited

Loading