Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 4 commits into from
Aug 19, 2018

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Aug 2, 2018

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
Copy link
Collaborator

r? @shepmaster

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

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

RalfJung commented Aug 2, 2018

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
Copy link
Collaborator

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
Copy link
Member Author

RalfJung commented Aug 2, 2018

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
Copy link
Member

@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
Copy link
Member Author

RalfJung commented Aug 2, 2018

@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
Copy link
Member Author

RalfJung commented Aug 2, 2018

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
Copy link
Member

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

@RalfJung
Copy link
Member Author

RalfJung commented Aug 2, 2018

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
Copy link
Contributor

Veedrac commented Aug 2, 2018

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

@RalfJung
Copy link
Member Author

RalfJung commented Aug 2, 2018

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

Now I wonder if align_to does that correct.

@RalfJung
Copy link
Member Author

RalfJung commented Aug 2, 2018

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

@RalfJung
Copy link
Member Author

RalfJung commented Aug 2, 2018

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

@rust-highfive
Copy link
Collaborator

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
Copy link
Member Author

RalfJung commented Aug 4, 2018

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

@llogiq
Copy link
Contributor

llogiq commented Aug 4, 2018

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
Copy link
Contributor

gnzlbg commented Aug 6, 2018

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
Copy link
Member Author

RalfJung commented Aug 6, 2018

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
Copy link
Contributor

gnzlbg commented Aug 6, 2018

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:

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

@rust-highfive
Copy link
Collaborator

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
Copy link
Member Author

RalfJung commented Aug 6, 2018

@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
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Aug 19, 2018

📌 Commit 1001b2b has been approved by alexcrichton

@bors 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
Copy link
Contributor

bors commented Aug 19, 2018

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

@bors
Copy link
Contributor

bors commented Aug 19, 2018

💔 Test failed - status-travis

@bors 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
@rust-highfive
Copy link
Collaborator

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
Copy link
Member

kennytm commented Aug 19, 2018

@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 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
Copy link
Contributor

bors commented Aug 19, 2018

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

bors added a commit that referenced this pull request Aug 19, 2018
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
Copy link
Contributor

bors commented Aug 19, 2018

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

@bors bors merged commit 1001b2b into rust-lang:master Aug 19, 2018
@rust-highfive
Copy link
Collaborator

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

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Aug 19, 2018
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
Copy link
Member

kennytm commented Aug 19, 2018

[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
Copy link
Member Author

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

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

@RalfJung
Copy link
Member Author

Submitted rust-lang/book#1492

@RalfJung RalfJung deleted the from_raw_parts_align branch September 1, 2018 09:07
Centril added a commit to Centril/rust that referenced this pull request Jan 14, 2019
…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.)
Centril added a commit to Centril/rust that referenced this pull request Jan 14, 2019
…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.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.