jiebi/CodeConvo huggingface dataset:
Change:
CargoClippy, "src/tools/clippy", "cargo-clippy", stable=true; Clippy, "src/tools/clippy", "clippy-driver", stable=true, add_bins_to_sysroot = ["clippy-driver", "cargo-clippy"]; Miri, "src/tools/miri", "miri", stable=false, add_bins_to_sysroot = ["miri"]; <del> CargoMiri, "src/tools/miri/cargo-miri", "cargo-miri", stable=true, add_bins_to_sysroot = ["cargo-miri"]; </del> <ins> CargoMiri, "src/tools/miri/cargo-miri", "cargo-miri", stable=false, add_bins_to_sysroot = ["cargo-miri"]; </ins> Rls, "src/tools/rls", "rls", stable=true; Rustfmt, "src/tools/rustfmt", "rustfmt", stable=true, add_bins_to_sysroot = ["rustfmt", "cargo-fmt"]; );

Discussion:
In the past, the default tools=[...] in included Miri. The default of building Miri was removed at and The latter is called “Do not build Miri by default”, and as it changes 1211 files obviously I do not follow what exactly it does. In any case, as in rustc-1.80.1-[build] # tools = [ "cargo", "clippy", "rustdoc", "rustfmt", "rust-analyzer", "rust-analyzer-proc-macro-srv", "analysis", "src", "rust-demangler", # if profiler = true] does not include miri, my understanding is that and should produce identical result (except for rust-analyzer-proc-macro-srv). But the first does lead to installing Miri, while the second skips installing Miri. As my observation is that now Miri is built by default (is part of the implicit tools=[…]), in tools= should indclude miri. To be precise the first ./configure I ran against rustc-1.79.0- and the second against rustc-1.80.1-
That PR shipped with Rust 1.66 so I'm not sure why you are linking it when you seem to be intending to report a change from Rust 1.79 to Rust 1.80.
I am not reporting a changbe between 1.79 and 1.80. I am saying that old Rust versions built Miri by default (miri was in the implicit tools=[]), then it was removed from tools=[], and now miri is again in the implicit tools=[], but not in [...]
The latter is called "Make miri a subtree instead of a submodule", which should give you an idea of why it changes so many files. ;) Cc ; I don't know if this was a deliberate change or not or how the implicit "tools" array is even computed. Miri is a nightly-only tool so we probably do not want it to be built implicitly on stable.
For dev/nightly channels, we simply build every tool by default: If channel isn't dev/nightly, we only build tools are are marked as and (although cargo-miri is) Miri isn't one of them.
Okay so if the sample is supposed to show the default it should show both of these, presumably?
Done that in ()
Change:
violations.push(ObjectSafetyViolation::SupertraitSelf); } <ins> violations.extend(self.associated_items(trait_def_id) .filter(|item| item.kind == ty::AssociatedKind::Const) .map(|item| ObjectSafetyViolation::AssociatedConst(item.name))); </ins> debug!("object_safety_violations_for_trait(trait_def_id={:?}) = {:?}", trait_def_id, violations);

Discussion:
The following code compiles: Furthermore, adding the line to causes an ICE:
I think the code should be legal to compile. It's impossible to get the value of from a variable (there's no such thing as where is a binding of type ).
Well it shouldn't compile
I don't know if this can lead to unsoundness or not. Correct me.
says no
Update on this, the example in the original post compiles today. But this ICEs: AFAICT there are two options here: consts are not object safe, just like associated (static) functions. consts must all be specified, just like associated types. I think its sensible to start with the first. The second makes more sense in the context of a world with const params, but the first can be extended to the second. It might also make sense some day to allow clauses on associated consts just like methods (and on associated types, for that matter, which connects in some degree with the ATC RFC).
Can't associated consts be part of the vtable/fat pointers?
Associated consts are inlined at compiletime, they can't have a value which is determined at runtime. This is a hard requirement for making things like const fn and const generics work. Associated statics could be object safe if they existed.
I think that having to write: instead of just: or is a pain. The value is determined at compile-time, but I am talking about being able to access that value at run-time via dynamic dispatch.
The value is not determined at compile time for the virtually dispatched type (the trait object type). What you want is the fields in traits RFC.
I did not say otherwise (the value is only determined at compile-time for the types that implement , not for itself or trait objects). What I did say is that currently there is no way to access this value at run-time without in my opinion unnecessary boilerplate but there should be one.
Maybe the problem is that traits support associated consts, and associated consts are values, but traits do not support associated values (yet).
Will they be object-safe in the future? I mean if "fn foo() -u8 where Self: Sized;" is already safe why are consts not?
Change:
type synthetic add -l lldb_lookup.synthetic_lookup -x ".*" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)String$" --category Rust <del> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&str$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&[.+]$" --category Rust </del> <ins> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&(mut )?str$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&(mut )?[.+]$" --category Rust </ins> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(std::ffi::([a-z_]+::)+)OsString$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)Vec<.+>$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)VecDeque<.+>$" --category Rust

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
<ins> fn main(){ } fn test_result() -> Result<(),()> { let a:Option<()> = Some(()); a?;//~ ERROR `?` couldn't convert the error Ok(()) } fn test_option() -> Option<i32>{ let a:Result<i32, i32> = Ok(5); a?;//~ ERROR `?` couldn't convert the error Some(5) } </ins>

Discussion:
It seems that should provide a better error message or hint when one tries to use the operator on an in a function returning a or vice-versa. Currently this is the error you get: However, it would be better to suggest the use of or , or , instead of referencing something dependent on the feature (). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This error is emitted here: We could look at whether the is , and if so, provide a more targeted error, including a structured suggestion for .
Can I claim this issue?
claim
Change:
use crate::traits::*; use rustc_hir::def_id::CrateNum; use rustc_index::vec::IndexVec; <ins> use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; </ins> use rustc_middle::mir; use rustc_middle::ty; use rustc_session::config::DebugInfo;

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
] [[package]] <ins> name = "crossbeam-queue" version = "0.3.5" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1f25d8400f4a7a5778f0e4e52384a48cbd9b5c495d110786187fc750075277a2" dependencies = [ "cfg-if 1.0.0", "crossbeam-utils", ] [[package]] </ins> name = "crossbeam-utils" version = "0.8.8" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.
Change:
<ins> error[E0608]: cannot index into a value of type `Map<[usize; 1], {closure@$DIR/bad-index-modulo-higher-ranked-regions.rs:23:32: 23:45}>` --> $DIR/bad-index-modulo-higher-ranked-regions.rs:23:55 | LL |     Map { inner: [0_usize], f: |_, i: usize| 1_usize }[0]; |                                                       ^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0608`. </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
Regression in nightly-2023-04-20 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests, r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3 ERROR: no CI builds available between and within last 167 days
Oh this might be contained in the first rollup ping reduced a bit: `
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
}; // Early-return cases. let val_val = match val.val { <del> ty::ConstKind::Param(_) => throw_inval!(TooGeneric), </del> <ins> ty::ConstKind::Param(_) | ty::ConstKind::Bound(..) => throw_inval!(TooGeneric), </ins> ty::ConstKind::Error(_) => throw_inval!(TypeckError(ErrorReported)), ty::ConstKind::Unevaluated(def, substs, promoted) => { let instance = self.resolve(def.did, substs)?;

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --Code from glacier: <!-- 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
NB: Only panics for me with the flag.
Change:
impl Input { pub fn filestem(&self) -> &str { <del> match *self { Input::File(ref ifile) => ifile.file_stem().unwrap().to_str().unwrap(), Input::Str { .. } => "rust_out", </del> <ins> if let Input::File(ifile) = self { // If for some reason getting the file stem as a UTF-8 string fails, // then fallback to a fixed name. if let Some(name) = ifile.file_stem().and_then(OsStr::to_str) { return name; } </ins> } <ins> "rust_out" </ins> } pub fn source_name(&self) -> FileName {

Discussion:
On a Windows machine, run: : Which is here: Specifically the panics. The device is pretty weird as it's a device in its own right that you can read/write to but also a kind of root directory (you can do ) and calling on should return . It doesn't quite fit with std's model of paths. <details<summary<strongBacktrace</strong</summary<p</p</details
To be clear, this is a strange thing to be doing so I wouldn't consider this a high priority or anything.
Change:
tcx.hir.krate().visit_all_item_likes(&mut visitor); for &(def_id, span) in tcx.maybe_unused_extern_crates(LOCAL_CRATE).iter() { <ins> // The `def_id` here actually was calculated during resolution (at least // at the time of this writing) and is being shipped to us via a side // channel of the tcx. There may have been extra expansion phases, // however, which ended up removing the `def_id` *after* expansion such // as the `ReplaceBodyWithLoop` pass (which is a bit of a hack, but hey) // // As a result we need to verify that `def_id` is indeed still valid for // our AST and actually present in the HIR map. If it's not there then // there's safely nothing to warn about, and otherwise we carry on with // our execution. // // Note that if we carry through to the `extern_mod_stmt_cnum` query // below it'll cause a panic because `def_id` is actually bogus at this // point in time otherwise. if let Some(id) = tcx.hir.as_local_node_id(def_id) { if tcx.hir.find(id).is_none() { continue } } </ins> let cnum = tcx.extern_mod_stmt_cnum(def_id).unwrap(); if tcx.is_compiler_builtins(cnum) { continue

Discussion:
On the latest nightly ( 2017-11-25) there's an ICE when generating the docs for the crate. Presumably somewhere along the line internal bookkeeping got confused and an invalid was generated (or a valid one was deleted), resulting in a panic during the phase 3 analysis passes. It looks like this is a regression in the latest nightly because it was works just fine on the build. Minimal Example: This was on an up-to-date Arch Linux machine.
For reference: ...
Simplified repro, no dependency needed:
Hold on, something's wrong. Edit: I've inverted the failure condition when bisecting The actual regressing commit is
The issue here is likely due to the everybody-loops pass moved to a different place. Previously it was called immediately after phase 1, now it is called in the middle of phase 2. I'm now trying to see if putting it at the end of phase 2 would help. If not we'd put it back to the beginning of phase 2. Edit: neither is working.
Also happens to
Can we prioritize fixing this? It looks like a relatively widespread problem...
Sure. Will take a look in the next days.
Minimized: I believe I see what's going on, will try to make a fix.
I've posted a fix for this issue at
Change:
}, Repeat { value: ExprRef<'tcx>, <del> // FIXME(#29789): Add a separate hair::Constant<'tcx> so this could be more explicit about // its contained data. Currently this should only contain expression of ExprKind::Literal // kind. count: ExprRef<'tcx>, </del> <ins> count: TypedConstVal<'tcx>, </ins> }, Vec { fields: Vec<ExprRef<'tcx>>,

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // ignore-android // ignore-arm // ignore-aarch64 #![feature(asm, rustc_attrs)] #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] #[rustc_error] pub fn main() { unsafe { // clobber formatted as register input/output asm!("xor %eax, %eax" : : : "{eax}"); //~^ ERROR clobber should not be surrounded by braces } } </ins>

Discussion:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.
Change:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error[E0658]: exclusive range pattern syntax is experimental --> $DIR/range_pat_interactions3.rs:12:18

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> LIB := $(shell $(RUSTC) --print-file-name --crate-type=lib lib.rs) $(TMPDIR)/$(LIB): $(RUSTC) --dep-info $(TMPDIR)/custom-deps-file.d --crate-type=lib lib.rs touch $(TMPDIR)/done -include $(TMPDIR)/custom-deps-file.d </ins>

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!
Change:
<ins> // This previously caused an ICE at: // librustc/traits/structural_impls.rs:180: impossible case reached #![no_main] use std::borrow::Borrow; use std::io; use std::io::Write; trait Constraint {} struct Container<T> { t: T, } struct Borrowed; struct Owned; impl<'a, T> Write for &'a Container<T> where T: Constraint, &'a T: Write, { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { Ok(buf.len()) } fn flush(&mut self) -> io::Result<()> { Ok(()) } } impl Borrow<Borrowed> for Owned { fn borrow(&self) -> &Borrowed { &Borrowed } } fn func(owned: Owned) { let _: () = Borrow::borrow(&owned); //~ ERROR mismatched types } </ins>

Discussion:
(Non-minimized) Repro case: It can correct fail with E0308 "mismatched types" if that line is removed. <details<summaryCrash log</summary</detailsThe ICE is repro with 1.27-beta and nightly. <details<summaryOn 1.26-stable, this will produce an infinite recursion instead.</summary</detailsMaybe the same as .
This, I think, can be closed: in nightly and 1.36.0 the code no longer produces an ICE and instead fails with an error "just fine".
Do you think you could create a minimal test to close this issue with?
This still needs a more minimal reproduction. I can't get to build using any of the compilers that are problematic. The reproduction should show what is happening from including that causes this issue.
Change:
// Make sure opening a drive will work. check("Z:", "Z:"); <del> // An empty path or a path that contains null are not valid paths. assert!(maybe_verbatim(Path::new("")).is_err()); </del> <ins> // A path that contains null is not a valid path. </ins> assert!(maybe_verbatim(Path::new("0")).is_err()); }

Discussion:
I tried this code: I expected to see this happen: returns os error 3 () Instead, this happened: it returns os error 123 () This is problematic as doesn't become but , which isn't useful for most users. Other platforms like Linux return so the former behavior should be correct here. : The issue doesn't happen on , I think the regression was introduced by .
Thanks for finding and fixing that! I do think that should be mapped to an . It means "The filename, directory name, or volume label syntax is incorrect". So a syntax error basically. But I don't think that should block your current PR.
Sounds good, maybe it should be ? (EDIT: Opened )
is it intentional that E-medium is instead of P-medium?
Oh oops.