Question:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

<ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>


Question:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

<ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>


Question:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>


Question:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

<ins> // aux-build: issue_24843.rs // check-pass extern crate issue_24843; static _TEST_STR_2: &'static str = &issue_24843::TEST_STR; fn main() {} </ins>


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

/// Typically doesn’t need to be used directly. #[unstable(feature = "convert_float_to_int", issue = "67057")] pub trait FloatToInt<Int>: private::Sealed + Sized { <del> #[unstable(feature = "float_approx_unchecked_to", issue = "67058")] </del> <ins> #[unstable(feature = "convert_float_to_int", issue = "67057")] </ins> #[doc(hidden)] <del> unsafe fn approx_unchecked(self) -> Int; </del> <ins> unsafe fn to_int_unchecked(self) -> Int; </ins> } macro_rules! impl_float_to_int {


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

impl FloatToInt<$Int> for $Float { #[doc(hidden)] #[inline] <del> unsafe fn approx_unchecked(self) -> $Int { crate::intrinsics::float_to_int_approx_unchecked(self) </del> <ins> unsafe fn to_int_unchecked(self) -> $Int { #[cfg(bootstrap)] { crate::intrinsics::float_to_int_approx_unchecked(self) } #[cfg(not(bootstrap))] { crate::intrinsics::float_to_int_unchecked(self) } </ins> } } )+


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

/// Convert with LLVM’s fptoui/fptosi, which may return undef for values out of range /// (<https://github.com/rust-lang/rust/issues/10184>) /// This is under stabilization at <https://github.com/rust-lang/rust/issues/67058> <ins> #[cfg(bootstrap)] </ins> pub fn float_to_int_approx_unchecked<Float: Copy, Int: Copy>(value: Float) -> Int; <ins> /// Convert with LLVM’s fptoui/fptosi, which may return undef for values out of range /// (<https://github.com/rust-lang/rust/issues/10184>) /// /// Stabilized as `f32::to_int_unchecked` and `f64::to_int_unchecked`. #[cfg(not(bootstrap))] pub fn float_to_int_unchecked<Float: Copy, Int: Copy>(value: Float) -> Int; </ins> /// Returns the number of bits set in an integer type `T` /// /// The stabilized versions of this intrinsic are available on the integer


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

/// * Not be `NaN` /// * Not be infinite /// * Be representable in the return type `Int`, after truncating off its fractional part <del> #[unstable(feature = "float_approx_unchecked_to", issue = "67058")] </del> <ins> #[stable(feature = "float_approx_unchecked_to", since = "1.44.0")] </ins> #[inline] <del> pub unsafe fn approx_unchecked_to<Int>(self) -> Int </del> <ins> pub unsafe fn to_int_unchecked<Int>(self) -> Int </ins> where Self: FloatToInt<Int>, { <del> FloatToInt::<Int>::approx_unchecked(self) </del> <ins> FloatToInt::<Int>::to_int_unchecked(self) </ins> } /// Raw transmutation to `u32`.


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

/// assuming that the value is finite and fits in that type. /// /// ``` <del> /// #![feature(float_approx_unchecked_to)] /// </del> /// let value = 4.6_f32; <del> /// let rounded = unsafe { value.approx_unchecked_to::<u16>() }; </del> <ins> /// let rounded = unsafe { value.to_int_unchecked::<u16>() }; </ins> /// assert_eq!(rounded, 4); /// /// let value = -128.9_f32; <del> /// let rounded = unsafe { value.approx_unchecked_to::<i8>() }; </del> <ins> /// let rounded = unsafe { value.to_int_unchecked::<i8>() }; </ins> /// assert_eq!(rounded, std::i8::MIN); /// ``` ///


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

/// * Not be `NaN` /// * Not be infinite /// * Be representable in the return type `Int`, after truncating off its fractional part <del> #[unstable(feature = "float_approx_unchecked_to", issue = "67058")] </del> <ins> #[stable(feature = "float_approx_unchecked_to", since = "1.44.0")] </ins> #[inline] <del> pub unsafe fn approx_unchecked_to<Int>(self) -> Int </del> <ins> pub unsafe fn to_int_unchecked<Int>(self) -> Int </ins> where Self: FloatToInt<Int>, { <del> FloatToInt::<Int>::approx_unchecked(self) </del> <ins> FloatToInt::<Int>::to_int_unchecked(self) </ins> } /// Raw transmutation to `u64`.


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

} } <del> "float_to_int_approx_unchecked" => { </del> <ins> "float_to_int_unchecked" => { </ins> if float_type_width(arg_tys[0]).is_none() { span_invalid_monomorphization_error( tcx.sess, span, &format!( <del> "invalid monomorphization of `float_to_int_approx_unchecked`  </del> <ins> "invalid monomorphization of `float_to_int_unchecked`  </ins> intrinsic: expected basic float type,  found `{}`", arg_tys[0]


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

tcx.sess, span, &format!( <del> "invalid monomorphization of `float_to_int_approx_unchecked`  </del> <ins> "invalid monomorphization of `float_to_int_unchecked`  </ins> intrinsic:  expected basic integer type,  found `{}`", ret_ty


Question:
First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

"fadd_fast" | "fsub_fast" | "fmul_fast" | "fdiv_fast" | "frem_fast" => { (1, vec![param(0), param(0)], param(0)) } <del> "float_to_int_approx_unchecked" => (2, vec![param(0)], param(1)), </del> <ins> "float_to_int_unchecked" => (2, vec![param(0)], param(1)), </ins> "assume" => (0, vec![tcx.types.bool], tcx.mk_unit()), "likely" => (0, vec![tcx.types.bool], tcx.types.bool),


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

"rand 0.7.0", "rustc-workspace-hack", "rustc_version", <ins> "serde", </ins> "shell-escape", "vergen", ]


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

<del> Subproject commit a0ba079b6af0f8c07c33dd8af72a51c997e58967 </del> <ins> Subproject commit 048af409232fc2d7f8fbe5469080dc8bb702c498 </ins>


Question:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

None => return Ok(()), }; <ins> // Render the replacements for each suggestion let suggestions = suggestion.splice_lines(&**sm); if suggestions.is_empty() { // Suggestions coming from macros can have malformed spans. This is a heavy handed // approach to avoid ICEs by ignoring the suggestion outright. return Ok(()); } </ins> let mut buffer = StyledBuffer::new(); // Render the suggestion message


Question:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

Some(Style::HeaderMsg), ); <del> // Render the replacements for each suggestion let suggestions = suggestion.splice_lines(&**sm); </del> let mut row_num = 2; let mut notice_capitalization = false; for (complete, parts, only_capitalization) in suggestions.iter().take(MAX_SUGGESTIONS) {


Question:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

let show_underline = !(parts.len() == 1 && parts[0].snippet.trim() == complete.trim()) && complete.lines().count() == 1; <del> let lines = sm.span_to_lines(parts[0].span).unwrap(); </del> <ins> let lines = sm .span_to_lines(parts[0].span) .expect("span_to_lines failed when emitting suggestion"); </ins> assert!(!lines.lines.is_empty());


Question:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

pub use emitter::ColorConfig; <ins> use log::debug; </ins> use Level::*; use emitter::{is_case_difference, Emitter, EmitterWriter};


Question:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

self.substitutions .iter() <ins> .filter(|subst| { // Suggestions coming from macros can have malformed spans. This is a heavy // handed approach to avoid ICEs by ignoring the suggestion outright. let invalid = subst.parts.iter().any(|item| cm.is_valid_span(item.span).is_err()); if invalid { debug!("splice_lines: suggestion contains an invalid span: {:?}", subst); } !invalid }) </ins> .cloned() .map(|mut substitution| { // Assumption: all spans are in the same file, and all spans


Question:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

lo.line != hi.line } <del> pub fn span_to_lines(&self, sp: Span) -> FileLinesResult { debug!("span_to_lines(sp={:?})", sp); </del> <ins> pub fn is_valid_span(&self, sp: Span) -> Result<(Loc, Loc), SpanLinesError> { </ins> let lo = self.lookup_char_pos(sp.lo()); debug!("span_to_lines: lo={:?}", lo); let hi = self.lookup_char_pos(sp.hi()); debug!("span_to_lines: hi={:?}", hi); if lo.file.start_pos != hi.file.start_pos { return Err(SpanLinesError::DistinctSources(DistinctSources { begin: (lo.file.name.clone(), lo.file.start_pos), end: (hi.file.name.clone(), hi.file.start_pos), })); } <ins> Ok((lo, hi)) } pub fn span_to_lines(&self, sp: Span) -> FileLinesResult { debug!("span_to_lines(sp={:?})", sp); let (lo, hi) = self.is_valid_span(sp)?; </ins> assert!(hi.line >= lo.line); let mut lines = Vec::with_capacity(hi.line - lo.line + 1);


Question:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

LL | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:346:17 </del> <ins> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:356:17 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic


Question:
Creating a stack closure which references an owned pointer and then transferring ownership of the owned box before invoking the stack closure results in a crash. For example, in Rust 0.6, this will compile and the resulting program will then crash with a SEGV
Does it still crash on the branch?
It dumps core for me, on incoming: Adding an xfailed test. We want this to fail compilation, I guess.
This bug could be fixed by the proposed solution in this post: (namely, bullet 1, not 2)
Dup of and more specifically .

<ins> //xfail-test // Creating a stack closure which references an owned pointer and then // transferring ownership of the owned box before invoking the stack // closure results in a crash. fn twice(x: ~uint) -> uint { *x * 2 } fn invoke(f : &fn() -> uint) { f(); } fn main() { let x  : ~uint         = ~9; let sq : &fn() -> uint = || { *x * *x }; twice(x); invoke(sq); } </ins>  No newline at end of file


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

if self.regioncx.universal_regions().is_universal_region(r) { Some(r) } else { <del> let upper_bound = self.regioncx.universal_upper_bound(r); </del> <ins> // We just want something nameable, even if it's not // actually an upper bound. let upper_bound = self.regioncx.approx_universal_upper_bound(r); </ins> if self.regioncx.upper_bound_in_region_scc(r, upper_bound) { self.to_error_region_vid(upper_bound)


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

lub } <ins> /// Like `universal_upper_bound`, but returns an approximation more suitable /// for diagnostics. If `r` contains multiple disjoint universal regions /// (e.g. 'a and 'b in `fn foo<'a, 'b> { ... }`, we pick the lower-numbered region. /// This corresponds to picking named regions over unnamed regions /// (e.g. picking early-bound regions over a closure late-bound region). /// /// This means that the returned value may not be a true upper bound, since /// only 'static is known to outlive disjoint universal regions. /// Therefore, this method should only be used in diagnostic code, /// where displaying *some* named universal region is better than /// falling back to 'static. pub(in crate::borrow_check) fn approx_universal_upper_bound(&self, r: RegionVid) -> RegionVid { debug!("approx_universal_upper_bound(r={:?}={})", r, self.region_value_str(r)); // Find the smallest universal region that contains all other // universal regions within `region`. let mut lub = self.universal_regions.fr_fn_body; let r_scc = self.constraint_sccs.scc(r); let static_r = self.universal_regions.fr_static; for ur in self.scc_values.universal_regions_outlived_by(r_scc) { let new_lub = self.universal_region_relations.postdom_upper_bound(lub, ur); debug!("approx_universal_upper_bound: ur={:?} lub={:?} new_lub={:?}", ur, lub, new_lub); if ur != static_r && lub != static_r && new_lub == static_r { lub = std::cmp::min(ur, lub); } else { lub = new_lub; } } debug!("approx_universal_upper_bound: r={:?} lub={:?}", r, lub); lub } </ins> /// Tests if `test` is true when applied to `lower_bound` at /// `point`. fn eval_verify_bound(


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

{ tcx.fold_regions(&ty, &mut false, |region, _| match *region { ty::ReVar(vid) => { <del> let upper_bound = self.universal_upper_bound(vid); </del> <ins> // Find something that we can name let upper_bound = self.approx_universal_upper_bound(vid); </ins> self.definitions[upper_bound].external_name.unwrap_or(region) } _ => region,


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

<ins> // edition:2018 // // Regression test for issue #67765 // Tests that we point at the proper location when giving // a lifetime error. fn main() {} async fn func<'a>() -> Result<(), &'a str> { let s = String::new(); let b = &s[..]; Err(b)?; //~ ERROR cannot return value referencing local variable `s` Ok(()) } </ins>


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

<ins> error[E0515]: cannot return value referencing local variable `s` --> $DIR/issue-67765-async-diagnostic.rs:13:11 | LL |     let b = &s[..]; |              - `s` is borrowed here LL | LL |     Err(b)?; |           ^ returns a value referencing data owned by the current function error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

fn main() { <del> [0].iter().flat_map(|a| [0].iter().map(|_| &a)); //~ ERROR `a` does not live long enough </del> <ins> [0].iter().flat_map(|a| [0].iter().map(|_| &a)); //~ ERROR closure may outlive </ins> }


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

<del> error[E0597]: `a` does not live long enough --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:49 </del> <ins> error[E0373]: closure may outlive the current function, but it borrows `a`, which is owned by the current function --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:44 </ins> | LL |     [0].iter().flat_map(|a| [0].iter().map(|_| &a)); <del> |                                             -   ^- ...but `a` will be dropped here, when the enclosing closure returns |                                             |   | |                                             |   `a` would have to be valid for `'_`... |                                             has type `&i32` </del> <ins> |                                            ^^^  - `a` is borrowed here |                                            | |                                            may outlive borrowed value `a` </ins> | <del> = note: functions cannot return a borrow to data owned within the function's scope, functions can only return borrows to data passed as arguments = note: to learn more, visit <https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#dangling-references> </del> <ins> note: closure is returned here --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:29 | LL |     [0].iter().flat_map(|a| [0].iter().map(|_| &a)); |                             ^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables), use the `move` keyword | LL |     [0].iter().flat_map(|a| [0].iter().map(move |_| &a)); |                                            ^^^^^^^^ </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0597`. </del> <ins> For more information about this error, try `rustc --explain E0373`. </ins>


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

<ins> // See https://github.com/rust-lang/rust/pull/67911#issuecomment-576023915 fn f<'a, 'b>(x: i32) -> (&'a i32, &'b i32) { let y = &x; (y, y) //~ ERROR cannot return } fn main() {} </ins>


Question:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

<ins> error[E0515]: cannot return value referencing function parameter `x` --> $DIR/return-disjoint-regions.rs:4:5 | LL |     let y = &x; |             -- `x` is borrowed here LL |     (y, y) |     ^^^^^^ returns a value referencing data owned by the current function error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>


Question:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::{ hir::place::PlaceBase, <del> mir::{self, ClearCrossCrate, Local, LocalDecl, LocalInfo, Location}, </del> <ins> mir::{self, ClearCrossCrate, Local, LocalDecl, LocalInfo, LocalKind, Location}, </ins> }; use rustc_span::source_map::DesugaringKind; use rustc_span::symbol::{kw, Symbol};


Question:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

match label { Some((true, err_help_span, suggested_code)) => { <del> err.span_suggestion( err_help_span, &format!( "consider changing this to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); </del> <ins> let (is_trait_sig, local_trait) = self.is_error_in_trait(local); if !is_trait_sig { err.span_suggestion( err_help_span, &format!( "consider changing this to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); } else if let Some(x) = local_trait { err.span_suggestion( x, &format!( "consider changing that to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); } </ins> } Some((false, err_label_span, message)) => { err.span_label(err_label_span, &message);


Question:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

err.buffer(&mut self.errors_buffer); } <ins> /// User cannot make signature of a trait mutable without changing the /// trait. So we find if this error belongs to a trait and if so we move /// suggestion to the trait or disable it if it is out of scope of this crate fn is_error_in_trait(&self, local: Local) -> (bool, Option<Span>) { if self.body.local_kind(local) != LocalKind::Arg { return (false, None); } let hir_map = self.infcx.tcx.hir(); let my_def = self.body.source.def_id(); let my_hir = hir_map.local_def_id_to_hir_id(my_def.as_local().unwrap()); let td = if let Some(a) = self.infcx.tcx.impl_of_method(my_def).and_then(|x| self.infcx.tcx.trait_id_of_impl(x)) { a } else { return (false, None); }; ( true, td.as_local().and_then(|tld| { let h = hir_map.local_def_id_to_hir_id(tld); match hir_map.find(h) { Some(Node::Item(hir::Item { kind: hir::ItemKind::Trait(_, _, _, _, items), .. })) => { let mut f_in_trait_opt = None; for hir::TraitItemRef { id: fi, kind: k, .. } in *items { let hi = fi.hir_id(); if !matches!(k, hir::AssocItemKind::Fn { .. }) { continue; } if hir_map.name(hi) != hir_map.name(my_hir) { continue; } f_in_trait_opt = Some(hi); break; } f_in_trait_opt.and_then(|f_in_trait| match hir_map.find(f_in_trait) { Some(Node::TraitItem(hir::TraitItem { kind: hir::TraitItemKind::Fn( hir::FnSig { decl: hir::FnDecl { inputs, .. }, .. }, _, ), .. })) => { let hir::Ty { span, .. } = inputs[local.index() - 1]; Some(span) } _ => None, }) } _ => None, } }), ) } </ins> // point to span of upvar making closure call require mutable borrow fn show_mutating_upvar( &self,


Question:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

<ins> use std::alloc::{GlobalAlloc, Layout}; struct Test(u32); unsafe impl GlobalAlloc for Test { unsafe fn alloc(&self, _layout: Layout) -> *mut u8 { self.0 += 1; //~ ERROR cannot assign 0 as *mut u8 } unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) { unimplemented!(); } } fn main() { } </ins>


Question:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

<ins> error[E0594]: cannot assign to `self.0` which is behind a `&` reference --> $DIR/issue-68049-1.rs:7:9 | LL |         self.0 += 1; |         ^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>


Question:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

<ins> trait Hello { fn example(&self, input: &i32); // should suggest here } struct Test1(i32); impl Hello for Test1 { fn example(&self, input: &i32) { // should not suggest here *input = self.0; //~ ERROR cannot assign } } struct Test2(i32); impl Hello for Test2 { fn example(&self, input: &i32) { // should not suggest here self.0 += *input; //~ ERROR cannot assign } } fn main() { } </ins>


Question:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

<ins> error[E0594]: cannot assign to `*input` which is behind a `&` reference --> $DIR/issue-68049-2.rs:9:7 | LL |   fn example(&self, input: &i32); // should suggest here |                            ---- help: consider changing that to be a mutable reference: `&mut i32` ... LL |       *input = self.0; |       ^^^^^^^^^^^^^^^ `input` is a `&` reference, so the data it refers to cannot be written error[E0594]: cannot assign to `self.0` which is behind a `&` reference --> $DIR/issue-68049-2.rs:17:5 | LL |   fn example(&self, input: &i32); // should suggest here |              ----- help: consider changing that to be a mutable reference: `&mut self` ... LL |     self.0 += *input; |     ^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0594`. </ins>


Question:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

self.sess.gated_spans.gate(sym::const_extern_fn, lo.to(self.token.span)); } let ext = self.parse_extern()?; <del> self.bump(); // `fn` </del> <ins> self.expect_keyword(kw::Fn)?; </ins> let header = FnHeader { unsafety,


Question:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

<ins> fn main() {} #[cfg(FALSE)] fn container() { const unsafe WhereIsFerris Now() {} //~^ ERROR expected one of `extern` or `fn` } </ins>


Question:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

<ins> error: expected one of `extern` or `fn`, found `WhereIsFerris` --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier-2.rs:5:18 | LL |     const unsafe WhereIsFerris Now() {} |                  ^^^^^^^^^^^^^ expected one of `extern` or `fn` error: aborting due to previous error </ins>


Question:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

<ins> fn main() {} #[cfg(FALSE)] fn container() { const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } //~^ ERROR expected `fn` //~| ERROR `const extern fn` definitions are unstable } </ins>


Question:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

<ins> error: expected `fn`, found `PUT_ANYTHING_YOU_WANT_HERE` --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier.rs:5:25 | LL |     const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `fn` error[E0658]: `const extern fn` definitions are unstable --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier.rs:5:5 | LL |     const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } |     ^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/64926 = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
has landed, so a fix should be possible now. are you on this or should I try my luck?
T-compiler triage: P-medium, removing nomination tag.

<del> Subproject commit 4e44aa010c4c7d616182a3078cafb39da6f6c0a2 </del> <ins> Subproject commit 6a0f14bef7784e57a57a996cae3f94dbd2490e7a </ins>


Question:
Hello, I'm in the process of upgrading Rust to 1.41.0 on Alpine Linux and it appears that a TEXTREL has been introduced in 1.41.0: The full build log is located here if it's of interest:
This apparently breaks Android builds, since that forbids text relocations
+1 I am one of the unfortunate winner of a release-blocking CI build failure for Android now that we've upgraded to 1.41.0. We've disabled android-x86 builds for now :(
I a minimal repro to my repository here: , in the hope that it can help debugging this (and because I was curious to dig into this myself :-) ). You can clone the repo, then In the container you can run . I bisected it using rustup and nightly releases, 2012-12-09 is good, 2019-12-10 is bad: When using nightly-2019-12-10:
Conveniently, no rollups! Auto merge of - tmandry:bump-compiler-builtins, r=alexcrichton Auto merge of - mark-i-m:fix-rustc-guide-2, r=ehuss Auto merge of - lqd:placeholder_loans, r=matthewjasper Auto merge of - estebank:issue-, r=eddyb Auto merge of - cjgillot:corrida, r=Mark-Simulacrum Auto merge of - GuillaumeGomez:move-clean-types, r=kinnison I would personally suspect . Can you try checking this via Specifically, comparing and ?
While rustup-toolchain-install-master compiles ( ): I see that upgrades compiler-builtins. I had a look at the commits in compiler-builtins which touch , and I think we can likely narrow it down to At this point I'm too much out of my depth, this needs people more knowledgeable than me . I hope I could help debugging this, and will continue watching the issue as I'm learning a great deal just by investigating this. Besides the actual fix, there are two additional things I'd love to understand: 1) why doesn't detect this? It looks like the obj file is not marked in any way has having a TEXTREL, but maybe the inline asm from that commit defines rustprobestack in such a way that relocating it needs touching the .text section (wild guess) 2) how would we go at testing this? Where in the rust project would I add a test for this? And given that scanelf can't detect this, maybe a good way to "integration test" this would be to build a minimal rust static lib, and try to link it into a shared object with like I'm doing in the repro code. Do I understand correctly that "all code produced by rustc should be relocatable" is a guaranteed property (thus worth testing), or am I completely mistaken?
Meanwhile, I can confirm that we got the right commit ():
triage: P-high. Assigning to self. Leaving nominated because I'd like to discuss this at today's meeting.
cc who did the rollup of compiler-builtins, do we know which of the following PRs may have caused the problem rust-lang/compiler-builtins (seems pretty clearly ok) rust-lang/compiler-builtins (remapping ? seems ok) rust-lang/compiler-builtins (modernize test crate, seems ok) rust-lang/compiler-builtins (atomic intrinsics? seems ok) rust-lang/compiler-builtins (atomic intrinsics? seems ok) rust-lang/compiler-builtins (gitmodules? probably ok) rust-lang/compiler-builtins (bcmp? seems ok) rust-lang/compiler-builtins (eliminate __fltused on uefi targets?) rust-lang/compiler-builtins (FFI unsafe warnings for i128/u128) rust-lang/compiler-builtins rust-lang/compiler-builtins hypothesizes , do you know that this could be the cause,
It could be. Likely the difference is in the attributes of the probestack function (before that change it was a rust function, afterward it was defined in raw assembly). could you try adding the line around ? If that fixes it, it may break it in other environments (e.g. when generating code for a shared vs static library). We'd probably need to thread some new cfg flags through, but I'm not sure if that's actually possible. The other way is going back to defining the assembly in a naked function, but , prevented me from doing this the first time. cc
cc (though they're on vacation this week I believe) on the inline assembly options as potentially relevant for RFC and if they have thoughts on how to fix it for this case
I would agree with the conclusion that is the most likely candidate here for a cause of the regression. That being said I have no idea what TEXTREL is, what's happening there to cause it, or how we might fix this.
Looking at the objdump output, you can see the difference between the 2019-12-09 and 2019-12-10 nightlies: The textrel happens because the has global visibility and can therefore (in theory) be overridden at runtime, e.g. with LDPRELOAD. This means that the dynamic linker will need to patch the .text section at load time to fix up the call instruction. As suggested, adding should fix the problem since the linker will then resolve references to the symbol within the shared library itself.
That's probably the correct fix then, I'm just not 100% sure it will work on all targets . If it fails we should see it in CI, though.
Will this be released in a 1.41.1, or should distros just apply this downstream? We'd very much like Rust 1.41.0 without TEXTRELs on x86.
Also, thanks for the quick fix of course :)
I would not currently wait for a 1.41.1 release. I hope that it will make it into 1.42 though.
Alright, thanks for the info.
Thanks for fixing this! I verified that this solves the issue on our end, and opened a PR with a simple regression test. The test fails on i686-unknown-linux-gnu when I revert compiler-builtins to 0.1.24.
I'm not sure this is the right place to bring it up, but without this fix it is impossible to deploy a rust static library to platforms that enforce properly-relocatable code (x86 android). It didn't make the cut for 1.41.1, is there any chance for 1.42? Can we help to make this happen? Thanks!
is beta nominated, it will be backported soon and included in 1.42 release.
Fantastic, thanks. Do you think it would be worth it to also include the regression test () in the release?
CCing the reviewers
awesome, I am waiting for a release with this fix. Any idea when 1.42 is planned?
Stable releases usually occur every 6 weeks, so it should land in ~2 weeks.
I've nominated the regression test as well!

[[package]] name = "compiler_builtins" <del> version = "0.1.24" </del> <ins> version = "0.1.25" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "b9975aefa63997ef75ca9cf013ff1bb81487aaa0b622c21053afd3b92979a7af" </del> <ins> checksum = "438ac08ddc5efe81452f984a9e33ba425b00b31d1f48e6acd9e2210aa28cc52e" </ins> dependencies = [ "cc", "rustc-std-workspace-core",


Question:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.

let post = format!(", consider renaming `{}` into `{snippet}`", suggestion.candidate); (span, snippet, post) } else { <del> (span, suggestion.candidate.to_string(), String::new()) </del> <ins> (span, suggestion.candidate.to_ident_string(), String::new()) </ins> }; let msg = match suggestion.target { SuggestionTarget::SimilarlyNamed => format!(


Question:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.

<ins> fn r#fn() {} fn main() { let r#final = 1; // Should correctly suggest variable defined using raw identifier. fina; //~ ERROR cannot find value // Should correctly suggest function defined using raw identifier. f(); //~ ERROR cannot find function } </ins>


Question:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.

<ins> error[E0425]: cannot find value `fina` in this scope --> $DIR/suggestion-raw-68962.rs:7:5 | LL |     fina; |     ^^^^ help: a local variable with a similar name exists: `r#final` error[E0425]: cannot find function `f` in this scope --> $DIR/suggestion-raw-68962.rs:10:5 | LL | fn r#fn() {} | --------- similarly named function `r#fn` defined here ... LL |     f(); |     ^ help: a function with a similar name exists: `r#fn` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>


Question:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

# Use LLVM libunwind as the implementation for Rust's unwinder. # Accepted values are 'in-tree' (formerly true), 'system' or 'no' (formerly false). <ins> # This option only applies for Linux and Fuchsia targets. # On Linux target, if crt-static is not enabled, 'no' means dynamic link to # `libgcc_s.so`, 'in-tree' means static link to the in-tree build of llvm libunwind # and 'system' means dynamic link to `libunwind.so`. If crt-static is enabled, # the behavior is depend on the libc. On musl target, 'no' and 'in-tree' both # means static link to the in-tree build of llvm libunwind, and 'system' means # static link to `libunwind.a` provided by system. Due to the limitation of glibc, # it must link to `libgcc_eh.a` to get a working output, and this option have no effect. </ins> #llvm-libunwind = 'no' # Enable Windows Control Flow Guard checks in the standard library.


Question:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

cc = "1.0.67" [features] <ins> # Only applies for Linux and Fuchsia targets # Static link to the in-tree build of llvm libunwind </ins> llvm-libunwind = [] <ins> # Only applies for Linux and Fuchsia targets # If crt-static is enabled, static link to `libunwind.a` provided by system # If crt-static is disabled, dynamic link to `libunwind.so` provided by system </ins> system-llvm-libunwind = []


Question:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

println!("cargo:rerun-if-changed=build.rs"); let target = env::var("TARGET").expect("TARGET was not set"); <del> if cfg!(feature = "system-llvm-libunwind") { </del> <ins> if cfg!(target_os = "linux") && cfg!(feature = "system-llvm-libunwind") { // linking for Linux is handled in lib.rs </ins> return; }