jiebi/CodeConvo huggingface dataset:
Change:
get_slice_bytes(&tcx, a_val) == get_slice_bytes(&tcx, b_val) } <ins> (ConstValue::ByRef { alloc: alloc_a, .. }, ConstValue::ByRef { alloc: alloc_b, .. }) if a.ty.is_ref() || b.ty.is_ref() => { if a.ty.is_ref() && b.ty.is_ref() { alloc_a == alloc_b } else { false } } </ins> (ConstValue::ByRef { .. }, ConstValue::ByRef { .. }) => { let a_destructured = tcx.destructure_const(relation.param_env().and(a)); let b_destructured = tcx.destructure_const(relation.param_env().and(b));

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. --Looks a bit like <!-- 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 --
Used as feature and got this: Regressed somewhere between ... <details<summaryBefore</summary</details<details<summaryAfter</summary</details
claim
Change:
pub fn stderr(&mut self, stderr: Stdio) { self.stderr = Some(stderr); } <ins> pub fn creation_flags(&mut self, flags: u32) { self.flags = flags; } </ins> pub fn spawn(&mut self, default: Stdio, needs_stdin: bool) -> io::Result<(Process, StdioPipes)> {

Discussion:
Now a tracking issue for on Windows. Open questions: Should we provide a method of adding* flags as opposed to setting them entirely? Would be a bit more composition-friendly. Also, don't forget to add to the prelude when stabilizing! There's a currently-unused codepath in the Windows implementation of that can set : It looks like historically there was a method to set this but it got removed. Unfortunately there's currently no way to set this, and no other way to set the flags, so for a project I'm working on I basically had to reimplement for Windows: I think we need some way to set this, even if it's Windows-specific. There are a bunch of other flags that can be specified, so maybe a way to set arbitrary flags would be useful? (v=vs.85).aspx I think this would fit nicely onto a Windows equivalent of the  trait, maybe something like:
Seems reasonable to me!
I'm always in favor of adding more Windows specific extension traits to expose useful functionality that other platforms don't seem to have.
I have a patch, it just took me a while to write a test for it. I'm trying to sort out the stability annotations for the new APIs--can I just use this issue as the tracking issue for the new feature?
Sure!
To the open question: I had first written the API as originally proposed: with a method to set the flags directly. Then I thought that might make it difficult if callers wanted to set different flags in different places, so I split it into and methods, but Alex asked me to change it back. I'm not sure it's that important, I don't think there are that many process creation flags that it would be useful to set from a library context, and callers can always aggregate flags into a u32 and just call with that value.
fcp merge With the one remaining open question I think it's safe to stabilize as this is still consistent with our approach to custom flags in other areas of platform-specific extensions as well.
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once 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: psst I wasn't able to add the label, please do so.
Change:
if cfg!(test) && !self.config.submodules() { return; } <del> self.update_submodule(submodule); </del> <ins> self.config.update_submodule(submodule); </ins> let absolute_path = self.config.src.join(submodule); if dir_is_empty(&absolute_path) { let maybe_enable = if !self.config.submodules()

Discussion:
<!-- 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: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
<ins> #![crate_name = "foo"] pub struct Body; impl Body { pub fn empty() -> Self { Body } } impl Default for Body { // @has foo/struct.Body.html '//a/@href' '../foo/struct.Body.html#method.empty' /// Returns [`Body::empty()`](Body::empty). fn default() -> Body { Body::empty() } } </ins>

Discussion:
<!-- 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: rustdoc generates intradoc links correctly Instead, this happened: rustdoc cannot resolve . <!-- 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. --: This looks like a regression from , cc modify labels: T-rustdoc A-intra-doc-links C-bug regression-from-stable-to-nightly
Found in
cc
Note I've already patched hyper by removing the link. A guess is that it's related to documenting a method from a trait implementstion ().
Ok, so i found the cause behind it and i'm working on the fix.
Removing label because we are mainly using them for and issues. I'm not aware that is using this label but please feel free to let me know if you find it useful. Otherwise we may not assign it to issues that are already tagged with , or .
it automatically, I think because I the regression label. I agree it doesn't belong on this issue.
Most regressions fall under the purview of , so adding makes sense as a default :)
just in case, I did this automation exactly for the reason described by What I'm suggesting now is that this automation may be better just adding the label if and only if the issue is not already tagged with , or .
Change:
<ins> // check-pass use std::cell::RefCell; pub fn f(v: Vec<RefCell<u8>>) { let _t = &mut *v[0].borrow_mut(); } fn main() {} </ins>

Discussion:
The whole example compiles it the implementation is removed.
I'm also running into something that appears to be this issue. I'm indexing a Vec, so the implementation of IndexMut is not under my control. I can try to make a reduced example using Vec if it would be helpful. EDIT: oh, it seems that already contains such an example.
Just wanted to note that I encountered this bug.
This . A simplified example: Workarounds include: extra braces: explicitly: explicitly:
This compiles now. Marking as needs-test (unsure if there is one that covers this already)
Change:
// worry about the other case: that is, if there is a move of a.b.c, it is already // marked as a move of a.b and a as well, so we will generate the correct errors // there. <del> let mut mpis = vec![mpi]; let move_paths = &self.move_data.move_paths; mpis.extend(move_paths[mpi].parents(move_paths).map(|(mpi, _)| mpi)); </del> for moi in &self.move_data.loc_map[location] { debug!("report_use_of_moved_or_uninitialized: moi={:?}", moi); let path = self.move_data.moves[*moi].path;

Discussion:
Forgetting to initialize a non-Copy variable in a loop and then referring to it gives a 'borrowed after move' error, instead of a 'possibly-uninitialized variable' error: Using a type like does result in the right error: Tested with 1.43.0 (stable) and 1.45.0-nightly.
In both Ada and D languages (in different ways, in Ada it's more refined) there's a way to tell the type system that the input variable to that bla function is not initialized and that bla must initialize it, and inside bla you can't read it before it's initialized. This means you have a way to propagate the not initialized state in function arguments, and safety is preserved. In practice this is not a big problem for Rust because in Rust you can return tuples and now Rustc is getting logic to optimize this usage pattern.
Uh, this issue is just about the error message. That this code gives an error is fine.
I'd be interested in fixing this myself, but I'm not sure where to start.
This is an issue for a command line program I'm writing. At the beginning of a function, I declare some uninitialized variables, and then I have a loop for each one. In this loop, it will read user input, and if it is valid, assign the variable that value. The loop will never complete without the variable being initialized, but rustc refuses to compile because it thinks the variable could be uninitialized after the loop.
That sounds like a different issue. This issue is about a confusing error message. The example is supposed to not compile. If the compiler rejects correct code, that's another issue.
To add context, I find this example illustrates the problem more clearly for me: the same code with the same types, just outside a loop context:
Change:
return; } <del> if let Some(hir_sig) = self.tcx.hir_node_by_def_id(item_def_id).fn_decl() { if hir_sig.output.get_infer_ret_ty().is_some() { let guar = self.tcx.dcx().span_delayed_bug( hir_sig.output.span(), "inferring return types and opaque types do not mix well", ); self.found = Some(ty::OpaqueHiddenType { span: DUMMY_SP, ty: Ty::new_error(self.tcx, guar), }); return; } </del> <ins> // Function items with `_` in their return type already emit an error, skip any // "non-defining use" errors for them. // Note that we use `Node::fn_sig` instead of `Node::fn_decl` here, because the former // excludes closures, which are allowed to have `_` in their return type. let hir_node = self.tcx.hir_node_by_def_id(item_def_id); debug_assert!( !matches!(hir_node, Node::ForeignItem(..)), "foreign items cannot constrain opaque types", ); if let Some(hir_sig) = hir_node.fn_sig() && hir_sig.decl.output.get_infer_ret_ty().is_some() { let guar = self.tcx.dcx().span_delayed_bug( hir_sig.decl.output.span(), "inferring return types and opaque types do not mix well", ); self.found = Some(ty::OpaqueHiddenType { span: DUMMY_SP, ty: Ty::new_error(self.tcx, guar) }); return; </ins> } // Calling `mir_borrowck` can lead to cycle errors through

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. -- (not minimized yet) searched nightlies: from nightly-2024-01-11 to nightly-2024-01-13 regressed nightly: nightly-2024-01-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
label -E-needs-mcve +S-has-mcve +F-impltraitinassoctype +requires-nightly
Change:
<ins> // compile-flags: -Zunpretty=hir // check-fail // In #100948 this caused an ICE with -Zunpretty=hir. fn main() { 1u; //~^ ERROR invalid suffix `u` for number literal } </ins>

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. --<!-- 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
Reduced: `
Regression in
The assert was in I MENT (sorry, I should no do this on the phone... :roll_eyes: ) cc
Change:
&[], ); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> cargo.arg("--").args(builder.config.cmd.test_args()); if try_run(builder, &mut cargo.into()) {

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
| = note: move occurs because `u` has type `U`, which does not implement the `Copy` trait <del> error[E0382]: use of moved value: `u` --> $DIR/borrowck-union-move-assign.rs:33:21 | LL |             let a = u.a; |                     --- value moved here LL |             u.a = A; LL |             let a = u.a; // OK |                     ^^^ value used here after move | = note: move occurs because `u` has type `U`, which does not implement the `Copy` trait error[E0382]: use of moved value: `u` --> $DIR/borrowck-union-move-assign.rs:39:21 | LL |             let a = u.a; |                     --- value moved here LL |             u.b = B; LL |             let a = u.a; // OK |                     ^^^ value used here after move | = note: move occurs because `u` has type `U`, which does not implement the `Copy` trait error: aborting due to 3 previous errors </del> <ins> error: aborting due to previous error </ins> For more information about this error, try `rustc --explain E0382`.

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
/// let dur = Duration::new(2, 700_000_000); /// // note that due to rounding errors result is slightly /// // different from 0.859_872_611 <del> /// assert_eq!(dur.div_f32(3.14), Duration::new(0, 859_872_576)); </del> <ins> /// assert_eq!(dur.div_f32(3.14), Duration::new(0, 859_872_579)); </ins> /// // note that truncation is used, not rounding /// assert_eq!(dur.div_f32(3.14e5), Duration::new(0, 8_598)); /// ```

Discussion:
Hello. I am diagnosing why I've got a wrong duration computed from Duration::fromsecsf32()... I tried this code: I expected to see an exact 30-second duration. Instead, I've got this: which is: 30 seconds and 1024 nanos. I dig deeper into rust code and I've prepared a sample code which is computing it based on the source code: As the result I've got: Instead of exact 30 seconds and 0 nanos.
?
Works on current stable and nightly: I mean, that this issue exist for that versions.
yep, I also confirmed on:
What is interesting the function: fromsecsf64 doesn't seem to have this problem... so a quick workaround would be use it and cast from f32 to f64
Extending(?) f32 to u128 gives this addition in 1024:
CC: CC: Adding authors ... guys please take a quick look if you have a time...
f32 will naturally have trouble representing all possible nanosecond values and so doing calculations in f64 may help here somewhat. However the most appropriate approach would be to decompose the float into the whole part and the fractional part and then operate on the two separately to produce the values necessary to create the . and may work sufficiently well for the purpose. EDIT: I think we would still need to be careful about how the nanosecond fraction is handled. We cannot simply multiply the number by and then convert to an integer, because is not capable of representing integers of such degree losslessly.
We cannot simply multiply the number by and then convert to an integer, because f32 is not capable of representing integers of such degree losslessly. Small correction: is represented exactly by , the problem is with . The closest float is , which results in the 1024 ns error. For example, would have produced an exact value. I would say such loss of precision is expected for and if you want exact values, you should use the integer based methods. So I don't think this issue should be marked as a bug. It could be worthwhile to improve the code by processing the fractional part separately, but note that it will not solve this issue fundamentally. We still have the issue of mapping at most 23 fractional bits into ~30 bits, e.g. calling would still result in an inexact result.

specifically may be representable exactly, but f32 cannot represent all integers exactly. Though maybe its not a huge deal if after we end up roundtripping back to the actual integer in all cases.
Argh, I forgot that the method is not available on , so the linked PR will not work out of box. UPD: I have implemented manual fraction/exponent splitting and their conversion to integers.
Change:
// Ignore drops, if the temp gets promoted, // then it's constant and thus drop is noop. // Storage live ranges are also irrelevant. <del> match context { LvalueContext::Drop | LvalueContext::StorageLive | LvalueContext::StorageDead => return, _ => {} </del> <ins> if context.is_drop() || context.is_storage_marker() { return; </ins> } let temp = &mut self.temps[index];

Discussion:
This code produces a compiler error with but compiles successfully with : The error is:
cc
This has to do with how the result of a checked op is a tuple and the 2's complement wrapping value is accessed through : the fix would be to track an initialization with a checked op in a field of , then treat as constant if is promotable and has that flag. I believe that the promoter will work as-is, it's just the constant qualifier that needs to understand this.
Looking at it again, the const qualifier works fine with fields, but the promoter's initial set of potentially promotable temporaries doesn't include the tuple because one of the uses is by-field.
Change:
ValueNS } <ins> #[deriving(Eq)] pub enum NamespaceError { NoError, ModuleError, TypeError, ValueError } </ins> /// A NamespaceResult represents the result of resolving an import in /// a particular namespace. The result is either definitely-resolved, /// definitely- unresolved, or unknown.

Discussion:
Code like Generates the error Which is wrong. is not a type, it's a module.
Change:
<ins> // check-pass #![allow(dead_code, incomplete_features)] #![feature(generic_const_exprs)] const fn min(a: usize, b: usize) -> usize { if a < b { a } else { b } } trait Trait1<Inner1> where Self: Sized, { fn crash_here() where Inner1: Default, { Inner1::default(); } } struct Struct1<T>(T); impl<T> Trait1<T> for Struct1<T> {} trait Trait2<Inner2> where Self: Sized, { type Assoc: Trait1<Inner2>; fn call_crash() where Inner2: Default, { // if Inner2 implements Default, we can call crash_here. Self::Assoc::crash_here(); } } struct Struct2<const SIZE1: usize, const SIZE2: usize> {} /* where [(); min(SIZE1, SIZE2)]:, { elem: [i32; min(SIZE1, SIZE2)], } */ impl<const SIZE1: usize, const SIZE2: usize> Trait2<[i32; min(SIZE1, SIZE2)]> for Struct2<SIZE1, SIZE2> { type Assoc = Struct1<[i32; min(SIZE1, SIZE2)]>; // dose Struct1<[i32; min(SIZE1, SIZE2)]> implement Default? } fn main() { pattern2(); print_fully_name(<Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::Assoc::crash_here); // <compiler_bug2::Struct1<[i32; 1]> as compiler_bug2::Trait1<[i32; 1]>>::crash_here } fn pattern1() { // no crash <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::Assoc::crash_here(); <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::call_crash(); } fn pattern2() { // crash <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::call_crash(); // undefined reference to `compiler_bug2::Trait1::crash_here' } fn pattern3() { // no crash <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::Assoc::crash_here(); } fn print_fully_name<T>(_: T) { let _ = std::any::type_name::<T>(); } </ins>

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. --In the situation using the genericconstexprs feature to specify the number of array elements, a linker error occurred in the Trait implementation. We minimized it as much as possible, but it could be more simplified. This is just a guess, but I think it is probably because the function signature is wrong. The error content claims that there is no "compilerbug2::Trait1::crashhere", although it should be "<compilerbug2::Struct1<[i32; 1]as compilerbug2::Trait1<[i32; 1]::crash_here". <!-- 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. --: </p</details
Triage: the issue no longer occurs with the latest nightly (I guess is related), could you check on your end?
Change:
<ins> { "arch": "x86_64", "is-builtin": true, "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128", "llvm-target": "x86_64-unknown-unknown-gnu", "target-pointer-width": "64" } </ins>

Discussion:
I'm new to Rust and I try to compile a project with a (I'm also new to that project and that project is not well organized.) when I use Makefile to make, the process of making executes and it reports it's a bug, so I'm here. I'm fresh here so if there is some information I don't provide, please tell me and I will try my best to provide it. Thank you! <!-- 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. --here I couldn't provide the example code since I don't really know the minimal set of code to be compiled the source code of the repo is in rustc should be in the nightly mode rust code is in the rust/sel4-rust/ in directory will execute in directory <!-- 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
Thank you for filing an issue! When I click that linked you posted, I get an error. Is it set that other people can view it?
Sorry, I have fixed the typo. Now the link should be right.(next time I will be more careful to check my issue)
The root of the issue is in the target definition file that the repository contains, however there are three other bugs that can be fixed in rustc: should not ICE when invalid external targets are being used; should report the actual target name/file in the error message, not the LLVM target name; target files are allowed to set the property.
The minimal target file to reproduce: with
( is a 404 )
Change:
| LL | use std::any:: as foo; |                ^^ expected identifier, found keyword <del> | help: you can escape reserved keywords to use them as identifiers | LL | use std::any:: r#as foo; |                ^^^^ </del> error: expected one of `::`, `;`, or `as`, found `foo` --> $DIR/use-as-where-use-ends-with-mod-sep.rs:1:19

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.