jiebi/CodeConvo huggingface dataset:
Change:
use types::os::arch::posix88::{uid_t}; pub type nlink_t = u16; <del> pub type blksize_t = i32; </del> <ins> pub type blksize_t = u32; </ins> pub type blkcnt_t = i64; pub type fflags_t = u32; #[repr(C)]

Discussion:
blksizet on 64-bit FreeBSD is 32 bits, not 64. on FreeBSD x8664 yields: yields: I tracked this down to the type definition, which is unconditionally 32-bit on FreeBSD (see , noting this line: this is unconditionally the definition of on FreeBSD - whether on 32-bit or 64-bit platform.)
Also, is a no-op (two fields of size 0) on 64-bit FreeBSD, the field can be deleted from the structure.
Change:
cargo.arg("-p").arg("clippy_dev"); // clippy_dev gets confused if it can't find `clippy/Cargo.toml` cargo.current_dir(&builder.src.join("src").join("tools").join("clippy")); <del> if builder.config.rust_optimize { </del> <ins> if builder.config.rust_optimize.is_release() { </ins> cargo.env("PROFILE", "release"); } else { cargo.env("PROFILE", "debug");

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
Some(val) => env::set_var("RUN_TEST_NEW_ENV", &val) } <del> let prog = cmd.spawn().unwrap(); let result = prog.wait_with_output().unwrap(); </del> <ins> let result = cmd.output().unwrap(); </ins> let output = String::from_utf8_lossy(&result.stdout); assert!(!output.contains("RUN_TEST_NEW_ENV"),

Discussion:
You can add a vector of command-line arguments to a Command object with , but there's no equivalent for environment variables. I'd like to be able to do things like let filteredenv : Vec<(String, String)= std::env::vars().filter( / criterion /).collect(); let status = Command::new("printenv") .stdin(Stdio::null()) .stdout(Stdio::inherit()) .envclear() .envs(filteredenv) .status(); Right now I have to do instead let mut cmd = Command::new("printenv"); (Stdio::null()); (Stdio::inherit()); cmd.envclear(); for (ref k, ref v) in filtered_env { (k, v); } let status = (); which breaks the builder pattern and extends the scope of the Command object.
This sounds reasonable to me considering . If you want to submit a PR for the feature go ahead.
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
I'm confused; hasn't this already been merged?
Yes, but it's currently . The FCP above starting means that the libs team believes the API is ready for stabilization.
Oh, ok. Thanks for the explanation.
The final comment period is now complete.
Change:
head.wrapping_add(self.one_lap) == tail & !self.mark_bit } } <del> impl<T> Drop for Channel<T> { fn drop(&mut self) { // Get the index of the head. let hix = self.head.load(Ordering::Relaxed) & (self.mark_bit - 1); // Loop over all slots that hold a message and drop them. for i in 0..self.len() { // Compute the index of the next slot holding a message. let index = if hix + i < self.cap { hix + i } else { hix + i - self.cap }; unsafe { debug_assert!(index < self.buffer.len()); let slot = self.buffer.get_unchecked_mut(index); let msg = &mut *slot.msg.get(); msg.as_mut_ptr().drop_in_place(); } } } } </del>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: I expected to see the struct in the Sender buffer get dropped after the Receiver is dropped during the unwind of the panicking thread. Instead, this happened: The data in the Sender buffer is not dropped until the whole process ends. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.66.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
bisection seems to point to cc searched nightlies: from nightly-2022-11-01 to nightly-2023-02-01 regressed nightly: nightly-2022-11-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
In crossbeam, the unbounded channel does this (), but the bounded channel does not. There is no particular intent, it just hasn't been implemented. cc
Change:
// index position where it *should have been*, which is *after* the previous one. if let Some(provided_idx) = provided_idx { prev = provided_idx.index() as i64; <ins> continue; </ins> } let idx = ProvidedIdx::from_usize((prev + 1) as usize); <del> if let None = provided_idx && let Some((_, arg_span)) = provided_arg_tys.get(idx) { </del> <ins> if let Some((_, arg_span)) = provided_arg_tys.get(idx) { prev += 1; </ins> // There is a type that was *not* found anywhere, so it isn't a move, but a // replacement and we look at what type it should have been. This will allow us // To suggest a multipart suggestion when encountering `foo(1, "")` where the def

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --You need rustc built with debug assertions in order to reproduce this! <!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let specialized = pat.specialize(pcx, &ctor); for (subpat, column) in specialized.iter().zip(&mut specialized_columns) { if subpat.is_or_pat() { <del> column.patterns.extend(subpat.iter_fields()) </del> <ins> column.patterns.extend(subpat.flatten_or_pat()) </ins> } else { column.patterns.push(subpat) }

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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
cc
Oh I see, nested or-patterns are usually flattened except not here because of the bindings! Fix incoming, thanks again
Change:
<ins> error[E0658]: trait objects in const fn are unstable --> $DIR/issue-55825-const-fn.rs:6:32 | LL | const fn no_dyn_trait_ret() -> &'static dyn std::fmt::Debug { &() } |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
Spawned off of (specificially in the project). Consider the following code: With AST-borrowck, you get (): With NLL (here using migration a la 2018 edition), you get (): I have not managed to replicate the above borrow-check error on code that does not exhibit some other error. And the problem goes away if you opt into (). So, this is really a very minor diagnostic issue.
Cc might be something in (min) const qualification?
TLDR: The issue with this is that we have a bunch of separate checks relating to const things, and most of these are spaghetti entangled into one. and I are working towards fixing that, but it's nontrivial to say the least. Details: We have the following checks that we need to run on MIR (which relate to const): minconstfn compliance constfn compliance promotion of runtime values to an anonymous static/constant const compliance (valid array length, const item initializer or enum discriminant) static compliance (valid static item initializer) no interior mutability checks no drop in const checks The current implementation has an early abort for const fns where if the feature gate is not active, we first run , and if that fails we don't run the entangled other 4 passes. If we ran the other passes in case of failure, you'd get a lot of error duplication. I don't think we have a tracking issue for the refactoring separating all these passes into distinct dataflow passes, but there's ongoing work.
This now produces the same output both with and without .
Change:
#[test] #[cfg_attr(target_os = "emscripten", ignore)] <ins> fn wait_until() { let pair = Arc::new((Mutex::new(false), Condvar::new())); let pair2 = pair.clone(); // Inside of our lock, spawn a new thread, and then wait for it to start. thread::spawn(move|| { let &(ref lock, ref cvar) = &*pair2; let mut started = lock.lock().unwrap(); *started = true; // We notify the condvar that the value has changed. cvar.notify_one(); }); // Wait for the thread to start up. let &(ref lock, ref cvar) = &*pair; let guard = cvar.wait_until(lock.lock().unwrap(), |started| { started }); assert!(*guard); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] </ins> fn wait_timeout_wait() { let m = Arc::new(Mutex::new(())); let c = Arc::new(Condvar::new());

Discussion:
Yes, another incarnation of . and also have this issue. Note that is an error and has a test for it. cc
Does this also date back to 1.0, like did?
Yes. The fix would be technically a breaking change.
Change:
packages: &'static [&'static str], features: Option<&'static [&'static str]>, manifest_path: Option<&'static str>, <ins> /// `filters` are passed to libtest (i.e., after a `--` in the `cargo test` invocation). filters: &'static [&'static str], </ins> } const TEST_REPOS: &[Test] = &[

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
panic!("an error message"); } let expected = "foobar"; <del> let failed_msg = "panic did not include expected string"; </del> <ins> let failed_msg = r#"panic did not contain expected string panic message: `"an error message"`, expected substring: `"foobar"`"#; </ins> let desc = TestDescAndFn { desc: TestDesc { name: StaticTestName("whatever"),

Discussion:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.
Change:
//! parent directory, and otherwise documentation can be found throughout the `build` //! directory in each respective module. <del> #[cfg(all(any(unix, windows), not(target_os = "solaris")))] </del> use std::io::Write; #[cfg(all(any(unix, windows), not(target_os = "solaris")))] use std::process;

Discussion:
While building latest Rust it fails like this: is the first bad commit commit Author: David Tolnay Date: Wed Nov 29 23:02:05 2023 -0800 Add ifletguard and let_chains pretty printer tests | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
do you have any idea about this? Thank you!
I am skeptical about that bisect. That commit is only adding tests. I do not see any way that it could cause bootstrap to fail to build.
Change:
Some(1u8).into_iter() } <ins> pub fn k() -> [impl Clone; 2] { [123u32, 456u32] } pub fn l() -> (impl Clone, impl Default) { (789u32, -123i32) } pub fn m() -> &'static impl Clone { &1u8 } pub fn n() -> *const impl Clone { &1u8 } pub fn o() -> &'static [impl Clone] { b":)" } // issue #44731 pub fn test_44731_0() -> Box<impl Iterator<Item=u8>> { Box::new(g()) } pub fn test_44731_1() -> Result<Box<impl Clone>, ()> { Ok(Box::new(j())) } pub fn test_44731_2() -> Box<Fn(impl Clone)> { Box::new(|_: u32| {}) } pub fn test_44731_3() -> Box<Fn() -> impl Clone> { Box::new(|| 0u32) } pub fn test_44731_4() -> Box<Iterator<Item=impl Clone>> { Box::new(g()) } </ins> // @has issue_43869/fn.g.html // @has issue_43869/fn.h.html // @has issue_43869/fn.i.html // @has issue_43869/fn.j.html <ins> // @has issue_43869/fn.k.html // @has issue_43869/fn.l.html // @has issue_43869/fn.m.html // @has issue_43869/fn.n.html // @has issue_43869/fn.o.html // @has issue_43869/fn.test_44731_0.html // @has issue_43869/fn.test_44731_1.html // @has issue_43869/fn.test_44731_2.html // @has issue_43869/fn.test_44731_3.html // @has issue_43869/fn.test_44731_4.html </ins>

Discussion:
` rustc -V rustc 1.22.0-nightly ( 2017-09-18)
Similar cause as . Repro case for :
Change:
<ins> error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-68366.rs:10:13 | LL | impl <const N: usize> Collatz<{Some(N)}> {} |             ^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-68366.rs:15:12 | LL | impl<const N: usize> Foo {} |            ^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0207`. </ins>

Discussion:
The following code does NOT compile: it errors with: However, when using normal generics in the places of the const generics, wrapping the in an and sticking that into the struct does work: Is it intended that const generic dont mimmic this behaviour?
This is probably a decision that has to be made (although if it is disallowed, then we'd want a better error message). However, at present, this is a implementation limitation: we really only properly support const generics of the form at the moment (cc ).
Considering that anon consts are mostly just projections, wouldn't this be similar to which doesn't really make a lot of sense (we have to guarantee that the projection maps each value of to a unique type). While is injective, finding an intuitive subset of expressions for which this is the case is hard and imo not actually desirable rn. Not quite sure what's the best error message though :thinking: probably something like
That's a good point I think adding a note explaining the problem would be the best solution, though the tricky part is working out how to explain it concisely (rather than just stating what the problem is).
Change:
// efficient initial-exec TLS model. This doesn't work with `dlopen`, // so we can't use it by default in general, but we can use it for tools // and our own internal libraries. <del> if !mode.must_support_dlopen() { </del> <ins> if !mode.must_support_dlopen() && !target.triple.starts_with("powerpc-") { </ins> rustflags.arg("-Ztls-model=initial-exec"); }

Discussion:
Since 1.49 beta, many tests fail on 32-bit PowerPC with the error that the test could not be compiled: I have not bisected the issue yet. Full log in: CC
I am seeing a lot of signal 4 (SIGILL) errors in the build log.
Ah, that reminds me of one bug in LLVM: I'll check whether this one fixes it:
Debian's LLVM 11 package () already contains the fix, so it can't be this. I'm trying to bisect this now in the Rust compiler itself but I just stumbled into the problem that a cross build no longer builds a full stage2 compiler with the std compiler which can be used on the target system, so I will first have to figure out what changed in Rust here.
You can pass to . The default changed to .
Thanks, that's what I guessed already, I just couldn't find the change in the vast amount of other changes ;).
Just cross-compiled 1.50 and the issue is still there:
I cannot get a sensible backtrace, unfortunately:
I'm bisecting this now. I think it might actually be a bug in the Rust compiler and not LLVM.
has lead me to :
At a first blush sounds like a limitation of the platform most likely (much like how it doesn't really support e.g. copy relocations all that well on PPC64) in which case a simple exclusion would make sense here.
I can confirm that reverting that change fixes the Rust compiler on 32-bit PowerPC for me. So, I agree, it should just be disabled on this target.
I can submit a simple patch either tonight or tomorrow some time.
there are reports of powerpc little endian toolchains still hitting this bug, can you imagine to push a simple patch to include the case of little endian as well? example:
...Does LLVM, or any of our codegen backends for that matter, actually support PowerPC 32-bit LE targets? Do they really exist? I know PowerPCs are bi-endian, but I thought the endian-switch bit was an extension that 32-bit architectures didn't have to include. Well, I do know we don't actually support any ppc32le Rust targets. I don't think it would exactly be what one would call a "maintenance burden" to accept a patch that adds a mild fix to bootstrap for custom targets.

But if people are really using this target, it might be better to submit an application to add it as a new tier 3 target, so we can at least be Formally Aware of it.
Yes.
Fair enough! The patch you ask for is simple so if you send it in we probably would happily accept it, but the best way to make sure Void Linux's targets are accounted for in the future would be to go through . For , it isn't required that it works well or passes tests. In fact, it isn't even required to build. However, merely having such support in the codebase would help with letting us know which tuples are actually in use, and thus reduce the likelihood of accidentally stomping on them.
Change:
.tcx .associated_items(did) .in_definition_order() <ins> .filter(|item| !item.is_impl_trait_in_trait()) </ins> .map(|item| clean_middle_assoc_item(item, cx)) .collect();

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim