jiebi/CodeConvo huggingface dataset:
Change:
When I compile a project with rust 1.73.0 on linux, I get a segmentation fault error. When I compile it with 1.72.1 all is well. How to reproduce on linux If reproduced, you should get this error If I do the same, but use 1.72.1, all is well.
Backtrace from a rustc build, tip of master with LLVM assertions and Rust debug assertions. No assertion of any kind is hit, we still segfault.
may make sense.
Here's the config I'm using: Am I missing something to enable sanitizers in LLVM?
Sorry, I'm actually not sure about the exact behavior of sanitizers here. We may need customized cmake settings, see: in
It's probably obvious, but I managed to bisect it to , which contains the commit that upgraded to LLVM 17 (). I didn't bisect individual commits because even on a beefy computing platform node it takes around 10 minutes to reach the segfault, and it's getting late here. I can also confirm the segfault only happens with , the build completes fine without it. Edit: managed to finish the bisection. searched nightlies: from nightly-2023-07-07 to nightly-2023-10-13 regressed nightly: nightly-2023-08-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Minimizing this is proving to be quite difficult, but I managed to pinpoint a change. In , changing any field assignment in the function of the structure (line 174) from the value to makes the segmentation fault disappear: Interestingly, while trying to go from and removing code to minimize the problem, the segmentation backtrace changed to this: I'm not nearly enough of an LLVM expert to understand if this is relevant, but I thought I'd include it in the event it is.
WG-prioritization assigning priority (). label -I-prioritize +P-high cc
Preliminary reduction:
Upstream issue:
This consistently fails with (signal: 11, SIGSEGV: invalid memory reference) for me on 1.73.0 (stable-aarch64-apple-darwin)
Can you please file a separate issue for that? It doesn't look related to this one.

Discussion:
<del> Subproject commit febc39711a7c91560eb0f0980916ae23c343b99d </del> <ins> Subproject commit fef3d7b14ede45d051dc688aae0bb8c8b02a0566 </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I have the following minimal example: It does as I expect and gives the error: However, since this enum is going to have more options to it in the future, for example, I go ahead and label it as : I would expect that this would disable the lint in this case. This is because, otherwise adding a implementation, e.g.: would then break when, in the future, I add my variant: with: In short, I would expect that adding would disable the lint as it's not future-proof, and the whole point of the attribute is to say "that a type or variant may have more fields or variants in the future". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Discussion:
if type_implements_negative_copy_modulo_regions(cx.tcx, ty, param_env) { return; } <ins> if def.is_variant_list_non_exhaustive() || def.variants().iter().any(|variant| variant.is_field_list_non_exhaustive()) { return; } </ins> // We shouldn't recommend implementing `Copy` on stateful things, // such as iterators.

<ins> // Test for issue #116766. // Ensure that we don't suggest impl'ing `Copy` for a type if it or at least one // of it's variants are marked as `non_exhaustive`. // check-pass #![deny(missing_copy_implementations)] #[non_exhaustive] pub enum MyEnum { A, } #[non_exhaustive] pub struct MyStruct { foo: usize, } pub enum MyEnum2 { #[non_exhaustive] A, B, } fn main() {} </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I expected to see this happen: The compiler compiles successfully or outputs an error message. Instead, this happened: The code, as provided below, appears to encounter a hang <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The same problem is reproduced on the nightly version(2023-10-15;) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This seems to be a type of quadratic blowup that changed in 1.73. I did some tests by altering the number of calls:
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-16 regressed nightly: nightly-2023-08-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details cc

Discussion:
let projected_term = selcx.infcx.resolve_vars_if_possible(projected_term); <del> let result = if projected_term.has_projections() { </del> <ins> let mut result = if projected_term.has_projections() { </ins> let mut normalizer = AssocTypeNormalizer::new( selcx, param_env,

); let normalized_ty = normalizer.fold(projected_term); <del> let mut deduped = SsoHashSet::with_capacity(projected_obligations.len()); projected_obligations.retain(|obligation| deduped.insert(obligation.clone())); </del> Normalized { value: normalized_ty, obligations: projected_obligations } } else { Normalized { value: projected_term, obligations: projected_obligations } }; <ins> let mut deduped = SsoHashSet::with_capacity(result.obligations.len()); result.obligations.retain(|obligation| deduped.insert(obligation.clone())); </ins> if use_cache { infcx.inner.borrow_mut().projection_cache().insert_term(cache_key, result.clone()); }
Change:
File: auto-reduced (treereduce-rust): original: Version information ` Command:
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
really need to add auto-bisection to icemaker reports... Regression in nightly-2021-04-26 found 9 bors merge commits in the specified range commit[0] 2021-04-24: Auto merge of - davidhewitt:revert-, r=GuillaumeGomez commit[1] 2021-04-24: Auto merge of - RalfJung:const-fn-feature-flags, r=oli-obk commit[2] 2021-04-25: Auto merge of - jyn514:no-span, r=GuillaumeGomez commit[3] 2021-04-25: Auto merge of - CDirkx:rt, r=m-ou-se commit[4] 2021-04-25: Auto merge of - cuviper:array-method-dispatch, r=nikomatsakis,m-ou-se commit[5] 2021-04-25: Auto merge of - RalfJung:black-box, r=Mark-Simulacrum commit[6] 2021-04-25: Auto merge of - lcnr:const-generics-defaults-name-res, r=varkor commit[7] 2021-04-25: Auto merge of - RalfJung:miri, r=RalfJung commit[8] 2021-04-25: Auto merge of - jsha:ephemeral-collapse, r=GuillaumeGomez maybe ?
hm, with , this crashes like this:
Hmm, I'm confused by the result of the bisection, I expected it to find a relatively recent commit since the reproducer doesn't ICE on stable (1.73) (while it does ICE on beta and nightly):
Doesn't ICE if is enabled.
this feature fixing an ice instead of causing one, that's a first...
This errors cleanly since beta 1.76.

Discussion:
<ins> // https://github.com/rust-lang/rust/issues/116796 struct X<const FN: fn() = { || {} }>; //~^ ERROR using function pointers as const generic parameters is forbidden fn main() {} </ins>

<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/default-ty-closure.rs:3:20 | LL | struct X<const FN: fn() = { || {} }>; |                    ^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 1 previous error </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code (): I expected to see this happen: When running , the format string literals for the first two s should remain valid string literals. Instead, this happened: This code is generated: Note the double and in the escapes. The escape sequences in the last are correctly preserved. This is annoying because it makes it impossible to run on the macro-expanded source, which is helpful when trying to read macro-generated code. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I haven't looked at it, but this is probably going wrong somewhere in when printing .
Looks like you’re right: As I understand this, it duplicates curlies regardless of whether they’re part of an escape sequence.
claim

Discussion:
for piece in pieces { match piece { FormatArgsPiece::Literal(s) => { <del> for c in s.as_str().escape_debug() { template.push(c); </del> <ins> for c in s.as_str().chars() { template.extend(c.escape_debug()); </ins> if let '{' | '}' = c { template.push(c); }

<ins> #![feature(prelude_import)] #![no_std] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // pretty-compare-only // pretty-mode:expanded // pp-exact:format-args-str-escape.pp fn main() { { ::std::io::_print(format_args!("u{1b}[1mHello, world!u{1b}[0mn")); }; { ::std::io::_print(format_args!("u{1b}[1mHello, world!u{1b}[0mn")); }; { ::std::io::_print(format_args!("Not an escape sequence: u{{1B}}[1mboldx1B[0mn")); }; { ::std::io::_print(format_args!("{0}n", "x1B[1mHello, world!x1B[0m")); }; } </ins>

<ins> // pretty-compare-only // pretty-mode:expanded // pp-exact:format-args-str-escape.pp fn main() { println!("x1B[1mHello, world!x1B[0m"); println!("u{1B}[1mHello, world!u{1B}[0m"); println!("Not an escape sequence: u{{1B}}[1mboldx1B[0m"); println!("{}", "x1B[1mHello, world!x1B[0m"); } </ins>
Change:
I asked stackoverflow about lifetime of variable. Original link is this :  Question from link I have a question about lifetime of varable in Rust programming language. function creates and returns r-value reference. and when it returns a reference, is destroyed. But () doesn't lead to crash. Why? (Is Test::print function called as static function?) Code Result** It happened with empty struct only. Is it a really bug?
Thanks for the report! I'm closing this as a dupe of and : the latter means that is of type , and the former means that it is legal to return this via an anonymous lifetime.
Oh, my apologies, I missed the implementation. This does seem like a bug with how Drop interacts with those two bugs I referenced above.
Nominating, this sounds bad.
Accepted for 1.0, P-backcompat-lang. Also, cc
I'm digging into this. if you've any pointers that would help debugging the issue, please let me know :smile:
I dug a bit into this. If what I looked into is correct, is being treated as a static item instead of being treated as an given the fact that it's no-Pod. This doesn't seem wrong for PODs but it should be for non-PODs. This is the borrowck log for the section:
you are correct, and it's just wrong all the time. We should treat unary structs and nullary enum variants as rvalues, not static items.
r?
is this actually fixed by ? I don't see a test case with a impl in that pull request.
reopening to ensure a test gets .
it is fixed. The issue had nothing to do w/ the but the fact that unary structs were treated as s. I'll add a cfail test for this specific case, anyway.

Discussion:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // This tests verifies that unary structs and enum variants // are treated as rvalues and their lifetime is not bounded to // the static scope. struct Test; impl Drop for Test { fn drop (&mut self) {} } fn createTest() -> &Test { let testValue = &Test; //~ ERROR borrowed value does not live long enough return testValue; } pub fn main() { createTest(); } </ins>
Change:
I tried this code: Also godbolt link I expected to see this happen: I was trying this code to see what kind of assemble the compilers makes. I tried different optimize levels. I see with optimize levels and , that the bits are still there but not used in the function. function is self takes about 5 instructions and the code about 40 instruction, which is dead code. Instead, this happened: bits removed in all the optimize levels. I was using a similar code on a embedded device. FYI: It also happens with . Remove the before 247. I see this happen on stable and nightly both for x86_64 and thumbv6/v7.
This is, unfortunately, well known. and aren't necessarily smaller 'll be optimized out in (which is opt-level=2).
Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.
maybe to clarify. With opt_level the assembly of the generated function is fine and optimized. But the bits are not removed and not used. so I am not sure if will help in this case.
does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the output to just one function.

Discussion:
/// assert!(!(0.0..f32::NAN).contains(&0.5)); /// assert!(!(f32::NAN..1.0).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

/// assert!( (3.0..f32::NAN).is_empty()); /// assert!( (f32::NAN..5.0).is_empty()); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_is_empty", since = "1.47.0")] pub fn is_empty(&self) -> bool { !(self.start < self.end)

/// assert!(!(0.0..).contains(&f32::NAN)); /// assert!(!(f32::NAN..).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

/// assert!(!(..1.0).contains(&f32::NAN)); /// assert!(!(..f32::NAN).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

/// // Precise field values are unspecified here /// assert!(!r.contains(&3) && !r.contains(&5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

/// assert!(!(..=1.0).contains(&f32::NAN)); /// assert!(!(..=f32::NAN).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

/// assert!(!(0.0..1.0).contains(&f32::NAN)); /// assert!(!(0.0..f32::NAN).contains(&0.5)); /// assert!(!(f32::NAN..1.0).contains(&0.5)); <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] fn contains<U>(&self, item: &U) -> bool where
Change:
I tried this code: I expected to see this happen: map = {1: "a"} Instead, error happened: Sometimes it causes Segmentation fault: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Miri reports UB with the target in question: (sorry for reflexively blaming LLVM, it didn't deserve that)
The root cause is that the stdarch SIMD intrinsics are broken on big-endian targets. For now I've disabled the use of NEON in hashbrown on big-endian ARM: We should probably disable/de-stabilize the NEON intrinsics on big-endian targets. They are currently all producing incorrect results.
All of them, or specifically for ARM? (Not sure if we have stdarch support for any other big-endian target.) Is there an issue tracking that and explaining in a bit more detail how they are broken?
This only applies to arm & aarch64 targets. Here is the issue in stdarch:
Miri doesn't support the NEON SIMD intrinsics though. So if Miri reports UB then it seems there are other problems as well?
Some are implemented using the same intrinsics as portable-simd.
It's a combination of a few things: We are missing a check for the NEON implementation. All the NEON intrinsics we happen to use in hashbrown are implemented without LLVM builtins.
Ah so I guess what happens is that Miri correctly implements the portable SIMD intrinsics, but stdarch implements the NEON intrinsics on top of them and it's doing that incorrectly? Miri and codegen/LLVM are fine?
Yes, that's my understanding.

Discussion:
[[package]] name = "hashbrown" <del> version = "0.14.0" </del> <ins> version = "0.14.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "2c6201b9ff9fd90a5a3bac2e56a830d0caa509576f0e503818ee82c181b3437a" </del> <ins> checksum = "f93e7192158dbcda357bdec5fb5788eebf8bbac027f3f33e719d29135ae84156" </ins> dependencies = [ "ahash", "allocator-api2",

checksum = "d5477fe2230a79769d8dc68e0eabf5437907c0457a5614a9e8dddb67f65eb65d" dependencies = [ "equivalent", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "rustc-rayon", "serde", ]

"compiler_builtins", "crc32fast", "flate2", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "indexmap 2.0.0", "memchr", "rustc-std-workspace-alloc",

"core", "dlmalloc", "fortanix-sgx-abi", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "hermit-abi 0.3.2", "libc", "miniz_oxide",

checksum = "4db52ee8fec06e119b692ef3dd2c4cf621a99204c1b8c47407870ed050305b9b" dependencies = [ "gimli", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "object", "tracing", ]
Change:
File: auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-06-02 Regression in cc

Discussion:
self.check_repeat_element_needs_copy_bound(element, count, element_ty); <del> self.register_wf_obligation( Ty::new_array_with_const_len(tcx, t, count).into(), expr.span, traits::WellFormed(None), ); </del> <ins> let ty = Ty::new_array_with_const_len(tcx, t, count); self.register_wf_obligation(ty.into(), expr.span, traits::WellFormed(None)); </ins> <del> Ty::new_array_with_const_len(tcx, t, count) </del> <ins> ty </ins> } fn check_repeat_element_needs_copy_bound(

if let Some(def_id) = self.typeck_results().type_dependent_def_id(id) { self.check_def_id(def_id); } else { <del> bug!("no type-dependent def for method"); </del> <ins> assert!( self.typeck_results().tainted_by_errors.is_some(), "no type-dependent def for method" ); </ins> } }

<ins> //! This test tests two things at once: //! 1. we error if a const evaluation hits the deny-by-default lint limit //! 2. we do not ICE on invalid follow-up code // compile-flags: -Z tiny-const-eval-limit </ins> fn main() { // Tests the Collatz conjecture with an incorrect base case (0 instead of 1). // The value of `n` will loop indefinitely (4 - 2 - 1 - 4). <del> let _ = [(); { </del> <ins> let s = [(); { </ins> let mut n = 113383; // #20 in https://oeis.org/A006884 while n != 0 { //~^ ERROR is taking a long time

} n }]; <ins> s.nonexistent_method(); </ins> }

error: constant evaluation is taking a long time <del> --> $DIR/infinite_loop.rs:6:9 </del> <ins> --> $DIR/infinite_loop.rs:12:9 </ins> | LL | /         while n != 0 { LL | |

= note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated <del> --> $DIR/infinite_loop.rs:4:18 </del> <ins> --> $DIR/infinite_loop.rs:10:18 </ins> | <del> LL |       let _ = [(); { </del> <ins> LL |       let s = [(); { </ins> |  __________________^ LL | |         let mut n = 113383; // #20 in https://oeis.org/A006884 LL | |         while n != 0 {
Change:
This has come up in two places recently: and We should do the following: On , document that is equivalent to Either before or after it lands, update the text in to document that "allocated objects" cannot contain the 0 address (alternatively, if that PR lands with text that says that an allocated object cannot contain the "null" address, update the text to mention that null is equal to 0) Are there other places we should update too? cc
there was some discussion in https://rust-
Int-to-ptr casts are terrible, I'd rather not do that. In fact these two are not equivalent for Miri (but that might be a Miri limitation, int2ptr is just hard or impossible to handle precisely for a tool like Miri). We should say that it returns a pointer whose address is 0, but we shouldn't commit to which provenance it has.
adds the docs for this.

Discussion:
/// Creates a null raw pointer. /// <ins> /// This function is equivalent to zero-initializing the pointer: /// `MaybeUninit::<*const T>::zeroed().assume_init()`. /// The resulting pointer has the address 0. /// </ins> /// # Examples /// /// ```

/// /// let p: *const i32 = ptr::null(); /// assert!(p.is_null()); <ins> /// assert_eq!(p as usize, 0); // this pointer has the address 0 </ins> /// ``` #[inline(always)] #[must_use]

/// Creates a null mutable raw pointer. /// <ins> /// This function is equivalent to zero-initializing the pointer: /// `MaybeUninit::<*mut T>::zeroed().assume_init()`. /// The resulting pointer has the address 0. /// </ins> /// # Examples /// /// ```

/// /// let p: *mut i32 = ptr::null_mut(); /// assert!(p.is_null()); <ins> /// assert_eq!(p as usize, 0); // this pointer has the address 0 </ins> /// ``` #[inline(always)] #[must_use]