jiebi/CodeConvo huggingface dataset:
Code change:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.

Related discussion:
text: // Linux. This was added in 2.6.28, however, and because we support // 2.6.18 we must detect this support dynamically. if cfg!(target_os = "linux") { <del> weak! { fn accept4(c_int, *mut sockaddr, *mut socklen_t, c_int) -> c_int </del> <ins> syscall! { fn accept4( fd: c_int, addr: *mut sockaddr, addr_len: *mut socklen_t, flags: c_int ) -> c_int </ins> } <del> if let Some(accept) = accept4.get() { let res = cvt_r(|| unsafe { accept(self.0.raw(), storage, len, SOCK_CLOEXEC) }); match res { Ok(fd) => return Ok(Socket(FileDesc::new(fd))), Err(ref e) if e.raw_os_error() == Some(libc::ENOSYS) => {} Err(e) => return Err(e), } </del> <ins> let res = cvt_r(|| unsafe { accept4(self.0.raw(), storage, len, SOCK_CLOEXEC) }); match res { Ok(fd) => return Ok(Socket(FileDesc::new(fd))), Err(ref e) if e.raw_os_error() == Some(libc::ENOSYS) => {} Err(e) => return Err(e), </ins> } }
Code change:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.

Related discussion:
text: } /// Sets the platform-specific value of errno <del> #[cfg(any(target_os = "solaris", target_os = "fuchsia"))] // only needed for readdir so far </del> <ins> #[cfg(all(not(target_os = "linux"), not(target_os = "dragonfly")))] // needed for readdir and syscall! </ins> pub fn set_errno(e: i32) { unsafe { *errno_location() = e as c_int
Code change:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.

Related discussion:
text: unsafe { errno as i32 } } <ins> #[cfg(target_os = "dragonfly")] pub fn set_errno(e: i32) { extern { #[thread_local] static mut errno: c_int; } unsafe { errno = e; } } </ins> /// Gets a detailed string description for the given error number. pub fn error_string(errno: i32) -> String { extern {
Code change:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.

Related discussion:
text: pub struct AnonPipe(FileDesc); pub fn anon_pipe() -> io::Result<(AnonPipe, AnonPipe)> { <del> weak! { fn pipe2(*mut c_int, c_int) -> c_int } </del> <ins> syscall! { fn pipe2(fds: *mut c_int, flags: c_int) -> c_int } </ins> static INVALID: AtomicBool = ATOMIC_BOOL_INIT; let mut fds = [0; 2];
Code change:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.

Related discussion:
text: }; libc::dlsym(libc::RTLD_DEFAULT, name.as_ptr()) as usize } <ins> #[cfg(not(target_os = "linux"))] macro_rules! syscall { (fn $name:ident($($arg_name:ident: $t:ty),*) -> $ret:ty) => ( unsafe fn $name($($arg_name: $t),*) -> $ret { use libc; use super::os; weak! { fn $name($($t),*) -> $ret } if let Some(fun) = $name.get() { fun($($arg_name),*) } else { os::set_errno(libc::ENOSYS); -1 } } ) } #[cfg(target_os = "linux")] macro_rules! syscall { (fn $name:ident($($arg_name:ident: $t:ty),*) -> $ret:ty) => ( unsafe fn $name($($arg_name:$t),*) -> $ret { // This looks like a hack, but concat_idents only accepts idents // (not paths). use libc::*; syscall( concat_idents!(SYS_, $name), $($arg_name as c_long),* ) as $ret } ) } </ins>
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: // Only allow statics (not consts) to refer to other statics. if self.mode == Mode::Static || self.mode == Mode::StaticMut { <del> if context.is_mutating_use() { </del> <ins> if self.mode == Mode::Static && context.is_mutating_use() { </ins> // this is not strictly necessary as miri will also bail out // For interior mutability we can't really catch this statically as that // goes through raw pointers and intermediate temporaries, so miri has
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: <ins> // compile-pass static mut STDERR_BUFFER_SPACE: [u8; 42] = [0u8; 42]; pub static mut STDERR_BUFFER: *mut [u8] = unsafe { &mut STDERR_BUFFER_SPACE }; fn main() {} </ins>
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: <ins> #![feature(const_let)] static mut STDERR_BUFFER_SPACE: u8 = 0; pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; //~^ ERROR references in statics may only refer to immutable values //~| ERROR static contains unimplemented expression type fn main() {} </ins>
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: <ins> error[E0017]: references in statics may only refer to immutable values --> $DIR/static_mut_containing_mut_ref2.rs:5:46 | LL | pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; |                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^ statics require immutable values error[E0019]: static contains unimplemented expression type --> $DIR/static_mut_containing_mut_ref2.rs:5:45 | LL | pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors Some errors occurred: E0017, E0019. For more information about an error, try `rustc --explain E0017`. </ins>
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: <ins> #![feature(const_let)] static mut FOO: (u8, u8) = (42, 43); static mut BAR: () = unsafe { FOO.0 = 99; }; //~^ ERROR could not evaluate static initializer fn main() {} </ins>
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: <ins> error[E0080]: could not evaluate static initializer --> $DIR/static_mut_containing_mut_ref3.rs:5:31 | LL | static mut BAR: () = unsafe { FOO.0 = 99; }; |                               ^^^^^^^^^^ tried to modify a static's initial value from another static's initializer error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: pub static mut A: u32 = 0; pub static mut B: () = unsafe { A = 1; }; <del> //~^ ERROR cannot mutate statics in the initializer of another static </del> <ins> //~^ ERROR could not evaluate static initializer </ins> pub static mut C: u32 = unsafe { C = 1; 0 }; <del> //~^ ERROR cannot mutate statics in the initializer of another static </del> <ins> //~^ ERROR cycle detected </ins> pub static D: u32 = D;
Code change:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

Related discussion:
text: <del> error: cannot mutate statics in the initializer of another static </del> <ins> error[E0080]: could not evaluate static initializer </ins> --> $DIR/write-to-static-mut-in-static.rs:14:33 | LL | pub static mut B: () = unsafe { A = 1; }; <del> |                                 ^^^^^ </del> <ins> |                                 ^^^^^ tried to modify a static's initial value from another static's initializer </ins> <del> error: cannot mutate statics in the initializer of another static </del> <ins> error[E0391]: cycle detected when const-evaluating `C` </ins> --> $DIR/write-to-static-mut-in-static.rs:17:34 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; |                                  ^^^^^ <ins> | note: ...which requires const-evaluating `C`... --> $DIR/write-to-static-mut-in-static.rs:17:1 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: ...which again requires const-evaluating `C`, completing the cycle note: cycle used when const-evaluating + checking `C` --> $DIR/write-to-static-mut-in-static.rs:17:1 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error: aborting due to 2 previous errors <ins> Some errors occurred: E0080, E0391. For more information about an error, try `rustc --explain E0080`. </ins>
Code change:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.

Related discussion:
text: }, } <ins> impl<'tcx> PatternKind<'tcx> { /// If this is a `PatternKind::AscribeUserType` then return the subpattern kind, otherwise /// return this pattern kind. fn with_user_type_ascription_subpattern(self) -> Self { match self { PatternKind::AscribeUserType { subpattern: Pattern { box kind, ..  }, ..  } => kind, kind => kind, } } } </ins> #[derive(Clone, Copy, Debug, PartialEq)] pub struct PatternRange<'tcx> { pub lo: ty::Const<'tcx>,
Code change:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.

Related discussion:
text: PatKind::Lit(ref value) => self.lower_lit(value), PatKind::Range(ref lo_expr, ref hi_expr, end) => { <del> match (self.lower_lit(lo_expr), self.lower_lit(hi_expr)) { (PatternKind::Constant { value: lo }, PatternKind::Constant { value: hi }) => { </del> <ins> match ( // Look for `PatternKind::Constant` patterns inside of any // `PatternKind::AscribeUserType` patterns. Type ascriptions can be safely // ignored for the purposes of lowering a range correctly - these are checked // elsewhere for well-formedness. self.lower_lit(lo_expr).with_user_type_ascription_subpattern(), self.lower_lit(hi_expr).with_user_type_ascription_subpattern(), ) { (PatternKind::Constant { value: lo }, PatternKind::Constant { value: hi }) => { </ins> use std::cmp::Ordering; let cmp = compare_const_vals( self.tcx,