Question:
The standard library provides a way to get the process id of a child process with , but doesn't have any way to get the current processes id (the equivalent of ). It is possible to do this with , but it seems to me that this should be something that is part of the standard library, especially since it already has cross-platform support for process ids of child processes.
Seems reasonable to add!
on Windows.
Reopening as the tracking issue.
While porting Rust over to , a sandboxed UNIX-like runtime environment, I ran into the issue that there is no way for me to implement this function. As we're aiming to use CloudABI in distributed settings, there is no traditional 16/32-bit process identifier. Instead, processes may be identified by a UUID. This is useful, as integer process identifiers can easily collide when dealing with many instances of a job (due to the birthday paradox). As this function was only introduced recently, would it still be possible to alter it to return an opaque, but displayable data type instead? That said, almost all of the other functions provided by this module are also broken on CloudABI. The traditional model doesn't lend well to sandboxing. Maybe it makes more sense to disable on CloudABI entirely.
I'm opposed a completely opaque data type, because that limits the usefulness. For example, that makes it difficult to use in C (or dbus) that require a PID. However, I think it would be alright if the it was a semi-opaque type with OS-specific API's to get the underlying representation (in std::os::unix, etc). However, that would break consistency with , which is already stabilized. I'm not sure how you would deal with that either.
As has mentioned, the ship has already sailed here due to . More generally, though. I'm not sure it makes sense to avoid supporting getpid of all things because some platform decided not to implement it.
One thing that would be low-hanging fruit would be to at least have some kind of type alias for this. On UNIX/Windows, it could be defined as . On CloudABI, it could be a string. That way, existing code that uses continues to build on existing platforms, whereas less conventional platforms can choose to implement this function differently.
Given this: and this: I’m inclined to stabilize as-is. (Returning .) fcp merge Hopefully the can eventually help a CloudABI port to "cleanly" implement this differently, or not at all.
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

pub fn exit(code: i32) -> ! { unsafe { libc::exit(code as c_int) } } <ins> pub fn getpid() -> u32 { unsafe { libc::getpid() as u32 } } </ins>


Question:
The standard library provides a way to get the process id of a child process with , but doesn't have any way to get the current processes id (the equivalent of ). It is possible to do this with , but it seems to me that this should be something that is part of the standard library, especially since it already has cross-platform support for process ids of child processes.
Seems reasonable to add!
on Windows.
Reopening as the tracking issue.
While porting Rust over to , a sandboxed UNIX-like runtime environment, I ran into the issue that there is no way for me to implement this function. As we're aiming to use CloudABI in distributed settings, there is no traditional 16/32-bit process identifier. Instead, processes may be identified by a UUID. This is useful, as integer process identifiers can easily collide when dealing with many instances of a job (due to the birthday paradox). As this function was only introduced recently, would it still be possible to alter it to return an opaque, but displayable data type instead? That said, almost all of the other functions provided by this module are also broken on CloudABI. The traditional model doesn't lend well to sandboxing. Maybe it makes more sense to disable on CloudABI entirely.
I'm opposed a completely opaque data type, because that limits the usefulness. For example, that makes it difficult to use in C (or dbus) that require a PID. However, I think it would be alright if the it was a semi-opaque type with OS-specific API's to get the underlying representation (in std::os::unix, etc). However, that would break consistency with , which is already stabilized. I'm not sure how you would deal with that either.
As has mentioned, the ship has already sailed here due to . More generally, though. I'm not sure it makes sense to avoid supporting getpid of all things because some platform decided not to implement it.
One thing that would be low-hanging fruit would be to at least have some kind of type alias for this. On UNIX/Windows, it could be defined as . On CloudABI, it could be a string. That way, existing code that uses continues to build on existing platforms, whereas less conventional platforms can choose to implement this function differently.
Given this: and this: I’m inclined to stabilize as-is. (Returning .) fcp merge Hopefully the can eventually help a CloudABI port to "cleanly" implement this differently, or not at all.
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

unsafe { c::ExitProcess(code as c::UINT) } } <ins> pub fn getpid() -> u32 { unsafe { c::GetCurrentProcessId() as u32 } } </ins> #[cfg(test)] mod tests { use io::Error;


Question: is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.

struct Void { _priv: (), <ins> /// Erases all oibits, because `Void` erases the type of the object that /// will be used to produce formatted output. Since we do not know what /// oibits the real types have (and they can have any or none), we need to /// take the most conservative approach and forbid all oibits. /// /// It was added after #45197 showed that one could share a `!Sync` /// object across threads by passing it into `format_args!`. _oibit_remover: PhantomData<*mut Fn()>, </ins> } /// This struct represents the generic "argument" which is taken by the Xprintf


Question: is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn send<T: Send>(_: T) {} fn sync<T: Sync>(_: T) {} fn main() { // `Cell` is not `Sync`, so `&Cell` is neither `Sync` nor `Send`, // `std::fmt::Arguments` used to forget this... let c = std::cell::Cell::new(42); send(format_args!("{:?}", c)); sync(format_args!("{:?}", c)); } </ins>


Question: is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.

<ins> error[E0277]: the trait bound `*mut std::ops::Fn() + 'static: std::marker::Sync` is not satisfied in `[std::fmt::ArgumentV1<'_>]` --> $DIR/send-sync.rs:18:5 | 18 |     send(format_args!("{:?}", c)); |     ^^^^ `*mut std::ops::Fn() + 'static` cannot be shared between threads safely | = help: within `[std::fmt::ArgumentV1<'_>]`, the trait `std::marker::Sync` is not implemented for `*mut std::ops::Fn() + 'static` = note: required because it appears within the type `std::marker::PhantomData<*mut std::ops::Fn() + 'static>` = note: required because it appears within the type `core::fmt::Void` = note: required because it appears within the type `&core::fmt::Void` = note: required because it appears within the type `std::fmt::ArgumentV1<'_>` = note: required because it appears within the type `[std::fmt::ArgumentV1<'_>]` = note: required because of the requirements on the impl of `std::marker::Send` for `&[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `std::fmt::Arguments<'_>` = note: required by `send` error[E0277]: the trait bound `*mut std::ops::Fn() + 'static: std::marker::Sync` is not satisfied in `std::fmt::Arguments<'_>` --> $DIR/send-sync.rs:19:5 | 19 |     sync(format_args!("{:?}", c)); |     ^^^^ `*mut std::ops::Fn() + 'static` cannot be shared between threads safely | = help: within `std::fmt::Arguments<'_>`, the trait `std::marker::Sync` is not implemented for `*mut std::ops::Fn() + 'static` = note: required because it appears within the type `std::marker::PhantomData<*mut std::ops::Fn() + 'static>` = note: required because it appears within the type `core::fmt::Void` = note: required because it appears within the type `&core::fmt::Void` = note: required because it appears within the type `std::fmt::ArgumentV1<'_>` = note: required because it appears within the type `[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `&[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `std::fmt::Arguments<'_>` = note: required by `sync` error: aborting due to 2 previous errors </ins>


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

#[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! format_args { ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! format_args { ($fmt:expr) => ({ /* compiler built-in */ }); ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }); } </ins> /// Inspect an environment variable at compile time. ///


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

#[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }); ($name:expr,) => ({ /* compiler built-in */ }); } </ins> /// Optionally inspect an environment variable at compile time. ///


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

#[macro_export] #[cfg(dox)] macro_rules! concat_idents { <del> ($($e:ident),*) => ({ /* compiler built-in */ }) </del> <ins> ($($e:ident),*) => ({ /* compiler built-in */ }); ($($e:ident,)*) => ({ /* compiler built-in */ }); </ins> } /// Concatenates literals into a static string slice.


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

#[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }); ($($e:expr,)*) => ({ /* compiler built-in */ }); } </ins> /// A macro which expands to the line number on which it was invoked. ///


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

/// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! format_args { ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! format_args { ($fmt:expr) => ({ /* compiler built-in */ }); ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }); } </ins> /// Inspect an environment variable at compile time. ///


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

/// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }); ($name:expr,) => ({ /* compiler built-in */ }); } </ins> /// Optionally inspect an environment variable at compile time. ///


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

#[unstable(feature = "concat_idents_macro", issue = "29599")] #[macro_export] macro_rules! concat_idents { <del> ($($e:ident),*) => ({ /* compiler built-in */ }) </del> <ins> ($($e:ident),*) => ({ /* compiler built-in */ }); ($($e:ident,)*) => ({ /* compiler built-in */ }); </ins> } /// Concatenates literals into a static string slice.


Question:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

/// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }); ($($e:expr,)*) => ({ /* compiler built-in */ }); } </ins> /// A macro which expands to the line number on which it was invoked. ///


Question:
We this to OccupiedEntry a while ago, but weirdly not to the map itself.
Should we also add ?
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

self.search_mut(k).into_occupied_bucket().map(|bucket| pop_internal(bucket).1) } <ins> /// Removes a key from the map, returning the stored key and value if the /// key was previously in the map. /// /// The key may be any borrowed form of the map's key type, but /// [`Hash`] and [`Eq`] on the borrowed form *must* match those for /// the key type. /// /// [`Eq`]: ../../std/cmp/trait.Eq.html /// [`Hash`]: ../../std/hash/trait.Hash.html /// /// # Examples /// /// ``` /// #![feature(hash_map_remove_entry)] /// use std::collections::HashMap; /// /// # fn main() { /// let mut map = HashMap::new(); /// map.insert(1, "a"); /// assert_eq!(map.remove_entry(&1), Some((1, "a"))); /// assert_eq!(map.remove(&1), None); /// # } /// ``` #[unstable(feature = "hash_map_remove_entry", issue = "46344")] pub fn remove_entry<Q: ?Sized>(&mut self, k: &Q) -> Option<(K, V)> where K: Borrow<Q>, Q: Hash + Eq { if self.table.size() == 0 { return None; } self.search_mut(k) .into_occupied_bucket() .map(|bucket| { let (k, v, _) = pop_internal(bucket); (k, v) }) } </ins> /// Retains only the elements specified by the predicate. /// /// In other words, remove all pairs `(k, v)` such that `f(&k,&mut v)` returns `false`.


Question:
We this to OccupiedEntry a while ago, but weirdly not to the map itself.
Should we also add ?
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

} #[test] <del> fn test_pop() { </del> <ins> fn test_remove() { </ins> let mut m = HashMap::new(); m.insert(1, 2); assert_eq!(m.remove(&1), Some(2));


Question:
We this to OccupiedEntry a while ago, but weirdly not to the map itself.
Should we also add ?
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

} #[test] <ins> fn test_remove_entry() { let mut m = HashMap::new(); m.insert(1, 2); assert_eq!(m.remove_entry(&1), Some((1, 2))); assert_eq!(m.remove(&1), None); } #[test] </ins> fn test_iterate() { let mut m = HashMap::with_capacity(4); for i in 0..32 {


Question:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

unsafe { let g = get_static(cx, def_id); <del> let v = match ::mir::codegen_static_initializer(cx, def_id) { </del> <ins> let (v, alloc) = match ::mir::codegen_static_initializer(cx, def_id) { </ins> Ok(v) => v, // Error has already been reported Err(_) => return,


Question:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

if attr::contains_name(attrs, "thread_local") { llvm::set_thread_local_mode(g, cx.tls_model); <ins> // Do not allow LLVM to change the alignment of a TLS on macOS. // // By default a global's alignment can be freely increased. // This allows LLVM to generate more performant instructions // e.g. using load-aligned into a SIMD register. // // However, on macOS 10.10 or below, the dynamic linker does not // respect any alignment given on the TLS (radar 24221680). // This will violate the alignment assumption, and causing segfault at runtime. // // This bug is very easy to trigger. In `println!` and `panic!`, // the `LOCAL_STDOUT`/`LOCAL_STDERR` handles are stored in a TLS, // which the values would be `mem::replace`d on initialization. // The implementation of `mem::replace` will use SIMD // whenever the size is 32 bytes or higher. LLVM notices SIMD is used // and tries to align `LOCAL_STDOUT`/`LOCAL_STDERR` to a 32-byte boundary, // which macOS's dyld disregarded and causing crashes // (see issues #51794, #51758, #50867, #48866 and #44056). // // To workaround the bug, we trick LLVM into not increasing // the global's alignment by explicitly assigning a section to it // (equivalent to automatically generating a `#[link_section]` attribute). // See the comment in the `GlobalValue::canIncreaseAlignment()` function // of `lib/IR/Globals.cpp` for why this works. // // When the alignment is not increased, the optimized `mem::replace` // will use load-unaligned instructions instead, and thus avoiding the crash. // // We could remove this hack whenever we decide to drop macOS 10.10 support. if cx.tcx.sess.target.target.options.is_like_osx { let sect_name = if alloc.bytes.iter().all(|b| *b == 0) { CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_bss0") } else { CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_data0") }; llvm::LLVMSetSection(g, sect_name.as_ptr()); } </ins> } base::set_link_section(cx, g, attrs);


Question:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

pub fn codegen_static_initializer<'a, 'tcx>( cx: &CodegenCx<'a, 'tcx>, def_id: DefId) <del> -> Result<ValueRef, Lrc<ConstEvalErr<'tcx>>> </del> <ins> -> Result<(ValueRef, &'tcx Allocation), Lrc<ConstEvalErr<'tcx>>> </ins> { let instance = ty::Instance::mono(cx.tcx, def_id); let cid = GlobalId {


Question:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

ConstValue::ByRef(alloc, n) if n.bytes() == 0 => alloc, _ => bug!("static const eval returned {:#?}", static_), }; <del> Ok(const_alloc_to_llvm(cx, alloc)) </del> <ins> Ok((const_alloc_to_llvm(cx, alloc), alloc)) </ins> } impl<'a, 'tcx> FunctionCx<'a, 'tcx> {


Question:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // ignore-tidy-linelength // only-macos // no-system-llvm // min-llvm-version 6.0 // compile-flags: -O #![crate_type = "rlib"] #![feature(thread_local)] // CHECK: @STATIC_VAR_1 = internal thread_local unnamed_addr global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4 #[no_mangle] #[allow(private_no_mangle_statics)] #[thread_local] static mut STATIC_VAR_1: [u32; 8] = [0; 8]; // CHECK: @STATIC_VAR_2 = internal thread_local unnamed_addr global <{ [32 x i8] }> <{{[^>]*}}>, section "__DATA,__thread_data", align 4 #[no_mangle] #[allow(private_no_mangle_statics)] #[thread_local] static mut STATIC_VAR_2: [u32; 8] = [4; 8]; #[no_mangle] pub unsafe fn f(x: &mut [u32; 8]) { std::mem::swap(x, &mut STATIC_VAR_1) } #[no_mangle] pub unsafe fn g(x: &mut [u32; 8]) { std::mem::swap(x, &mut STATIC_VAR_2) } </ins>


Question:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // only-x86_64 // no-prefer-dynamic // compile-flags: -Ctarget-feature=+avx -Clto fn main() {} </ins>


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

self.cx } <del> fn do_not_inline(&mut self, _llret: RValue<'gcc>) { </del> <ins> fn apply_attrs_to_cleanup_callsite(&mut self, _llret: RValue<'gcc>) { </ins> unimplemented!(); }


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

unsafe { llvm::LLVMBuildZExt(self.llbuilder, val, dest_ty, UNNAMED) } } <del> fn do_not_inline(&mut self, llret: &'ll Value) { llvm::Attribute::NoInline.apply_callsite(llvm::AttributePlace::Function, llret); </del> <ins> fn apply_attrs_to_cleanup_callsite(&mut self, llret: &'ll Value) { // Cleanup is always the cold path. llvm::Attribute::Cold.apply_callsite(llvm::AttributePlace::Function, llret); // In LLVM versions with deferred inlining (currently, system LLVM < 14), // inlining drop glue can lead to exponential size blowup, see #41696 and #92110. if !llvm_util::is_rust_llvm() && llvm_util::get_version() < (14, 0, 0) { llvm::Attribute::NoInline.apply_callsite(llvm::AttributePlace::Function, llret); } </ins> } }


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

pub fn LLVMRustVersionMinor() -> u32; pub fn LLVMRustVersionPatch() -> u32; <ins> pub fn LLVMRustIsRustLLVM() -> bool; </ins> pub fn LLVMRustAddModuleFlag(M: &Module, name: *const c_char, value: u32); pub fn LLVMRustMetadataAsValue<'a>(C: &'a Context, MD: &'a Metadata) -> &'a Value;


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

} } <ins> /// Returns `true` if this LLVM is Rust's bundled LLVM (and not system LLVM). pub fn is_rust_llvm() -> bool { // Can be called without initializing LLVM unsafe { llvm::LLVMRustIsRustLLVM() } } </ins> pub fn print_passes() { // Can be called without initializing LLVM unsafe {


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

let llret = bx.call(fn_ty, fn_ptr, &llargs, self.funclet(fx)); bx.apply_attrs_callsite(&fn_abi, llret); if fx.mir[self.bb].is_cleanup { <del> // Cleanup is always the cold path. Don't inline // drop glue. Also, when there is a deeply-nested // struct, there are "symmetry" issues that cause // exponential inlining - see issue #41696. bx.do_not_inline(llret); </del> <ins> bx.apply_attrs_to_cleanup_callsite(llret); </ins> } if let Some((ret_dest, target)) = destination {


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

) -> Self::Value; fn zext(&mut self, val: Self::Value, dest_ty: Self::Type) -> Self::Value; <del> fn do_not_inline(&mut self, llret: Self::Value); </del> <ins> fn apply_attrs_to_cleanup_callsite(&mut self, llret: Self::Value); </ins> }


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

extern "C" uint32_t LLVMRustVersionMajor() { return LLVM_VERSION_MAJOR; } <ins> extern "C" bool LLVMRustIsRustLLVM() { #ifdef LLVM_RUSTLLVM return true; #else return false; #endif } </ins> extern "C" void LLVMRustAddModuleFlag(LLVMModuleRef M, const char *Name, uint32_t Value) { unwrap(M)->addModuleFlag(Module::Warning, Name, Value);


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

<ins> // no-system-llvm: needs #92110 // compile-flags: -Cno-prepopulate-passes #![crate_type = "lib"] // This test checks that drop calls in unwind landing pads // get the `cold` attribute. // CHECK-LABEL: @check_cold // CHECK: call void {{.+}}drop_in_place{{.+}} [[ATTRIBUTES:#[0-9]+]] // CHECK: attributes [[ATTRIBUTES]] = { cold } #[no_mangle] pub fn check_cold(f: fn(), x: Box<u32>) { // this may unwind f(); } </ins>


Question:
The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.

<ins> // no-system-llvm: needs #92110 + patch for Rust alloc/dealloc functions // compile-flags: -Copt-level=3 #![crate_type = "lib"] // This test checks that we can inline drop_in_place in // unwind landing pads. // Without inlining, the box pointers escape via the call to drop_in_place, // and LLVM will not optimize out the pointer comparison. // With inlining, everything should be optimized out. // See https://github.com/rust-lang/rust/issues/46515 // CHECK-LABEL: @check_no_escape_in_landingpad // CHECK: start: // CHECK-NEXT: ret void #[no_mangle] pub fn check_no_escape_in_landingpad(f: fn()) { let x = &*Box::new(0); let y = &*Box::new(0); if x as *const _ == y as *const _ { f(); } } // Without inlining, the compiler can't tell that // dropping an empty string (in a landing pad) does nothing. // With inlining, the landing pad should be optimized out. // See https://github.com/rust-lang/rust/issues/87055 // CHECK-LABEL: @check_eliminate_noop_drop // CHECK: start: // CHECK-NEXT: call void %g() // CHECK-NEXT: ret void #[no_mangle] pub fn check_eliminate_noop_drop(g: fn()) { let _var = String::new(); g(); } </ins>


Question:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

pub fn span_err(&self, sp: Span, m: &str) { self.sess.span_diagnostic.span_err(sp, m) } <ins> pub fn struct_span_err(&self, sp: Span, m: &str) -> DiagnosticBuilder<'a> { self.sess.span_diagnostic.struct_span_err(sp, m) } </ins> pub fn span_err_help(&self, sp: Span, m: &str, h: &str) { let mut err = self.sess.span_diagnostic.mut_span_err(sp, m); err.help(h);


Question:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

let lo = self.span; let hi; <del> if self.check(&token::DotDot) { </del> <ins> if self.check(&token::DotDot) || self.token == token::DotDotDot { if self.token == token::DotDotDot { // Issue #46718 let mut err = self.struct_span_err(self.span, "expected field pattern, found `...`"); err.span_suggestion(self.span, "to omit remaining fields, use one fewer `.`", "..".to_owned()); err.emit(); } </ins> self.bump(); if self.token != token::CloseDelim(token::Brace) { let token_str = self.this_token_to_string();


Question:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![allow(unused)] struct PersonalityInventory { expressivity: f32, instrumentality: f32 } impl PersonalityInventory { fn expressivity(&self) -> f32 { match *self { PersonalityInventory { expressivity: exp, ... } => exp //~^ ERROR expected field pattern, found `...` } } } fn main() {} </ins>


Question:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.

<ins> error: expected field pattern, found `...` --> $DIR/issue-46718-struct-pattern-dotdotdot.rs:21:55 | 21 |             PersonalityInventory { expressivity: exp, ... } => exp |                                                       ^^^ help: to omit remaining fields, use one fewer `.`: `..` error: aborting due to previous error </ins>


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

} #[unstable(feature = "control_flow_enum", reason = "new API", issue = "75744")] <ins> #[cfg(bootstrap)] </ins> impl<B, C> ops::TryV1 for ControlFlow<B, C> { type Output = C; type Error = B;


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

mod generator; mod index; mod range; <ins> #[cfg(bootstrap)] </ins> mod r#try; mod try_trait; mod unsize;


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

pub use self::r#try::Try; #[unstable(feature = "try_trait_transition", reason = "for bootstrap", issue = "none")] <ins> #[cfg(bootstrap)] </ins> pub(crate) use self::r#try::Try as TryV1; #[unstable(feature = "try_trait_v2", issue = "84277")]


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

#[rustc_diagnostic_item = "none_error"] #[unstable(feature = "try_trait", issue = "42327")] #[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)] <ins> #[cfg(bootstrap)] </ins> pub struct NoneError; #[unstable(feature = "try_trait", issue = "42327")] <ins> #[cfg(bootstrap)] </ins> impl<T> ops::TryV1 for Option<T> { type Output = T; type Error = NoneError;


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

} #[unstable(feature = "try_trait", issue = "42327")] <ins> #[cfg(bootstrap)] </ins> impl<T, E> ops::TryV1 for Result<T, E> { type Output = T; type Error = E;


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

} #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[cfg(bootstrap)] </ins> impl<T, E> ops::TryV1 for Poll<Result<T, E>> { type Output = Poll<T>; type Error = E;


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

} #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[cfg(bootstrap)] </ins> impl<T, E> ops::TryV1 for Poll<Option<Result<T, E>>> { type Output = Poll<Option<T>>; type Error = E;


Question:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .

#![feature(str_internals)] #![feature(test)] #![feature(trusted_len)] <del> #![feature(try_trait)] </del> #![feature(try_trait_v2)] #![feature(slice_internals)] #![feature(slice_partition_dedup)]


Question:
Originally reported here: I don't understand the following sentence: Could someone parse this for me? To me, it reads like "to free memory allocated by a Vec v, create a new Vec w and drop it (i.e., w)". This is obviously not what it is intended. What's the role of the second Vec? Is this only in a context where v is empty but its memory not yet freed? If so, why wouldn't shrinktofit work in that case?
This refers to unsafe code that e.g. uses to allocate memory, and then s the to use the buffer in different ways (e.g., passing it to C, or implement a custom data structure over the allocated memory).

/// types inside a `Vec`, it will not allocate space for them. *Note that in this case /// the `Vec` may not report a [`capacity`] of 0*. `Vec` will allocate if and only /// if [`mem::size_of::<T>`]`() * capacity() > 0`. In general, `Vec`'s allocation <del> /// details are subtle enough that it is strongly recommended that you only /// free memory allocated by a `Vec` by creating a new `Vec` and dropping it. </del> <ins> /// details are very subtle — if you intend to allocate memory using a `Vec` /// and use it for something else (either to pass to unsafe code, or to build your /// own memory-backed collection), be sure to deallocate this memory by using /// `from_raw_parts` to recover the `Vec` and then dropping it. </ins> /// /// If a `Vec` *has* allocated memory, then the memory it points to is on the heap /// (as defined by the allocator Rust is configured to use by default), and its


Question:
In core, fails maybe a few times per month. Linux x86_64. I have no further information.
alright, i don't suppose you'd happen to have any logs of the times it failed? I haven't been able to reproduce the test failing (i.e., the test function terminating successfully). Looking over the unwrap implementation I think it's basically impossible for the test to fail with a localized bug, since it's testing two linked-failure tasks who go through code that looks like this: so I think it is safe to say that exactly one of the tasks will hit the . What's more, the test case itself has the parent thread (the one the test harness will block on) block on its child using a future_result. Either the parent will hit the die above (in which case the test case will surely pass), or the child will hit it, in which case the child's failure should link to the parent through the parent's call (I checked the linked failure code to make sure taskgroup killing happens before AutoNotify messaging). So it might be just as likely the race is in getting failed out of the recv call. So far I've experimented adding delays into various parts of the unwrap implementation to see which paths this test actually exercises (the state space is not very large, so it is not a Research Problem :P ), but not seen the bug in any yet. Will continue the search another day. EDIT: reproduction successful. (I'd forgotten that there was a difference in failure semantics between when the tasks are in the main/root taskgroup and when they're running as a #[test]! Argh.) More later.
Would you believe this is the minimized test case for this bug? No unwrap involved at all. Depending on the sleep, the test will either work or not (i.e., the problem is when a failing task sends to its futureresult before the parent even starts to receive on it, the linked failure doesn't take effect). I'm not sure if this is an intended nondeterminism of , but I definitely wrote assuming it wouldn't happen that way. anyway one possible way to fix this is to change the last line of the test case to (which doesn't weaken the test case). I will meditate on this more to decide if that's the best way.
OK, what's going on here is linked failure doesn't propagate through a in the special case where the pipe has data and the task doesn't need to block for it. To "fix" this nondeterminism at its source would involve putting a check in the case of . As another example, consider this program, whose main task always succeeds. "Fixing" the nondetermism above would make this program sometimes succeed (if the parent recvs before the child sends) and sometimes fail (if the child sends and fails before the parent recvs). Introducing the extra killed check wouldn't require taking a lock (see ). But, I've always punted on the semantics of when a linked failure killing takes effect, and adding this check feels like a patchwork special-case rather than a principled semantics change. might have input on the matter?
Adding the check seems reasonable to me. In the case of failure, I think it's fine if things are somewhat nondeterministic, so I don't think it's a problem if the program above sometimes failed. What if we a sleep before ? It seems like in that case you'd want this to always fail, unless you turned off link failure.
Thanks for looking into this. I understand how misses its opportunity to fail but not why the 'assert' has any effect. This is similar to a problem I frequently run into where I expect test cases like this to work (by failing):
Yeah, those are annoying cases. It might be nice to have a spawn interface that, while letting the parent go off and do its own thing, also makes the parent block on the child (on all such children spawned this way) before actually task-exiting. This could be done with on top of a generalised interface, or it could work by stashing s inside the parent's and having the destructor wait on each one in the destructor (which is essentially a hardcoded version of how would also work).

res.recv(); } <del> #[test] #[should_fail] #[ignore(cfg(windows))] </del> <ins> #[test] #[should_fail] #[ignore(reason = "random red")] </ins> pub fn exclusive_unwrap_conflict() { let x = exclusive(~~"hello"); let x2 = ~mut Some(x.clone());


Question:
This seems to be related to , though not entirely the same. I am in the process of ing my crate (multiple crates in a workspace project) v0.5.0 (from ). Instead of a normal compile process, I got this: :
I experienced this error now multiple times. Maybe it is a good idea to include the complete build output here:
With I get this error in a different form:
For the record: works on all crates where this bug was triggered (though I did not test all of them, just some).
For whatever reason, this is making it effectively impossible for me to package projects with lots of dependencies for Nix.
I can reliably hit this bug when compiling my project () with Nix
I believe this is a bug in our rustc package in nixpkgs, we appear to build it against which is bugged: https://nix- Maybe it would be a good idea to have a hard dependency on for rustc?
There is an issue here: rustc version 1.22.1 has in its lockfile, and the nix build appears to reliably trigger this bug while compiling . So we have a problem in nixpkgs that we cannot bootstrap using the binary distribution from rust- you are the author of , is there something we could do to workaround this bug for bootstrapping ? Or is it necessary to use a patched for compiling ?
the workaround would be to remove any ambient jobservers and let cargo/rustc manage it, if any
Can't we bootstrap using 1.23.0 binaries?
I can reliably hit this bug as well in nix
I can reliably hit this bug using . As far as I am aware I don't have any jobservers running.
I realized that the following issue was only occurring on nightly. However after the latest update this is now occurring on stable as well.
still persists using seems to happen because of this:
Can you please take another look at this. It appears that your diagnosis is wrong and many people are experiencing this issue. There is no workaround as far as I can tell and this is seriously workflow disrupting.
A misconfigured jobserver can still cause issues in rustc, and this error is indicative of a misconfigured jobserver in one way or another. This indicates an environmental problem rather than a problem in rustc AFAIK. If someone else manages to fix rustc we can of course merge, but I don't personally believe there's much we can do in rustc for this.
There is no other jobserver in my environment. I have checked numerous ways and am highly confident.
I am also getting the same error as when running entr with the reload flag. Throws the following error: According to the entr documentation whats happening is : 1) immediately start the server 2) block until any of the listed files change 3) terminate the background process 4) wait for the server to exit before restarting
I created an upstream issue for as well - it surrounds closing STDIN, which was in later versions for compatibility with some programs reasons - seems it then breaks with .
It sounds like the underlying issue is
A workaround for those using : It works for me with and 1.40.0 on Linux.
This is no longer happening for me. I don't know what has changed but I don't see this anymore.
It still happens for me with and . Just tested it with and got a panic starting with the same bit.
So, I've found an entirely legitimate way to trigger this error (the "early EOF on jobserver pipe" case) on new versions of , without having stdin closed or anything other exotic setup. If you call from an outer -based build system then will receive file descriptors for the jobserver pipe through an env var called . Except that new versions of will mark those descriptors as so they will be either dead or, worse, replaced with other random files when tries to access them :D The solution is to prevent from closing the pipe by using string anywhere in the command. (Yep, that's how works - ) This is silly, but it seems like doesn't leave any other way to inherit jobserver (at least not readily available from higher level makefile generators).
was recently facing similar issue while trying to run cargo build inside a makefile with buildroot was facing this everytime when i run cargo build Build fails: error: failed to acquire jobserver token: Bad file descriptor (os error 9) This worked for me. MAKEFLAGS= JOBS= cargo build
If you are actually running cargo inside of make you are hitting a different problem and I recommend opening a different issue. This issue was about a bug where no job server was running. This issue was fixed.

#[cfg(not(test))] pub fn init() { <ins> // The standard streams might be closed on application startup. To prevent // std::io::{stdin, stdout,stderr} objects from using other unrelated file // resources opened later, we reopen standards streams when they are closed. unsafe { sanitize_standard_fds(); } </ins> // By default, some platforms will send a *signal* when an EPIPE error // would otherwise be delivered. This runtime doesn't install a SIGPIPE // handler, causing it to kill the program, which isn't exactly what we