jiebi/CodeConvo huggingface dataset:
Change:
} Options.DataSections = DataSections; Options.FunctionSections = FunctionSections; <ins> Options.MCOptions.AsmVerbose = AsmComments; Options.MCOptions.PreserveAsmComments = AsmComments; </ins> if (TrapUnreachable) { // Tell LLVM to codegen `unreachable` into an explicit trap instruction.

Discussion:
clang -S produces nicely commented .s files. It would be nice if rustc did this too. e.g. simd shuffles are commented .loc directives have the corresponding line number comment .loc 1 4 25 isstmt 1 ## test.c:4:25 debug information is commented .byte 14 ## DWFORMstrp .byte 17 ## DWATlowpc .byte 1 ## DWFORMaddr .byte 18 ## DWAThighpc .byte 1 ## DWFORM_addr
There might be a or flag already for this. AFAIK what clang emits comes from LLVM.
This flag is already , should be usable (issue can be closed?):
Any reason not to make this the default?
Likely the fact that it may change the behavior (I don't actually know what that means but this seems like a valid assumption).
it looks like -Z asm-comments doesn't do this. MCOptions.AsmVerbose must be set to true for the assembler to emit them.
So it looks like -Zasm-comments isn't actually used anywhere based on what I can find in the source... or, rather, its uses are in methods that are themselves never called.
Yeah, to get comments I believe I needed to set a verbose flag in some llvm context. Clang does this by default and it would be nice if rustc did too.
IIUC without this neither the playground nor godbolt (compiler-explorer) can map assembly to lines of Rust source code.
Godbolt uses debug info AFAIK? Our debug info isn't always great but in general it's working, isn't it?
It seems like they just don't do it much. Godbolt uses directives in the assembly file, which rustc seems to generate correctly, sorry for the noise.
Change:
UnresolvedFloatTy(FloatVid), UnresolvedTy(TyVid), UnresolvedConst(ConstVid), <ins> UnresolvedEffect(EffectVid), </ins> } /// See the `region_obligations` field for more information.

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: is not fully resolved', 'error: internal compiler error: is not fully resolved' File: --Another regression of snippet: 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<!-- query stack: [checkmodimpl_wf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
This is caused by the fact that  does not check for const effect vars when visiting . It should be relatively simple to match on in the folder.
Working on this one.
Change:
} // Normalize lifetimes away on both sides, then compare. <del> let param_env = param_env.with_reveal_all_normalized(tcx); </del> let normalize = |ty: Ty<'tcx>| { tcx.normalize_erasing_regions( param_env,

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] type A = impl Sized; fn f1() -> A { 0 } type B = impl ?Sized; fn f2() -> &'static B { &[0] } type C = impl ?Sized + 'static; fn f3() -> &'static C { &[0] } type D = impl ?Sized; fn f4() -> &'static D { &1 } fn main() {} </ins>

Discussion:
Note to self (or whoever wants to help out); the following should be as a test case in : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I would like to work on this.
assign
Change:
fn run(self, builder: &Builder<'_>) -> Option<PathBuf> { let compiler = self.compiler; let target = self.target; <del> let tool = self.tool; </del> <ins> let mut tool = self.tool; </ins> let path = self.path; let is_optional_tool = self.is_optional_tool;

Discussion:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.
Change:
} } <ins> fn check_mir_test_timestamp(&self, test_name: &str, output_file: &Path) { let t = |file| FileTime::from_last_modification_time(&fs::metadata(file).unwrap()); let source_file = &self.testpaths.file; let output_time = t(output_file); let source_time = t(source_file); if source_time > output_time { debug!("source file time: {:?} output file time: {:?}", source_time, output_time); panic!("test source file `{}` is newer than potentially stale output file `{}`.", source_file.display(), test_name); } } </ins> fn compare_mir_test_output(&self, test_name: &str, expected_content: &Vec<&str>) { let mut output_file = PathBuf::new(); output_file.push(self.get_mir_dump_dir()); output_file.push(test_name); debug!("comparing the contests of: {:?}", output_file); debug!("with: {:?}", expected_content); <ins> self.check_mir_test_timestamp(test_name, &output_file); </ins> let mut dumped_file = fs::File::open(output_file.clone()).unwrap(); let mut dumped_string = String::new();

Discussion:
Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this: Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place. This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. , you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file). The user error here is of course that the needs to be kept in sync with the actual node number to which the mir dump sends its output. But it would be much better if did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.
(I have a patch for this; will post shortly)
Change:
} } <ins> /** * Creates and initializes an immutable managed vector by moving all the * elements from an owned vector. */ fn from_owned<T>(v: ~[T]) -> @[T] { let mut av = @[]; unsafe { raw::reserve(&mut av, v.len()); do vec::consume(v) |_i, x| { raw::push(&mut av, x); } transmute(av) } } /** * Creates and initializes an immutable managed vector by copying all the * elements of a slice. */ fn from_slice<T:Copy>(v: &[T]) -> @[T] { from_fn(v.len(), |i| v[i]) } </ins> #[cfg(notest)] pub mod traits { use at_vec::append;

Discussion:
Currently has constructor functions including , , , and . As far as I understand, none of these allow constructing an by moving (rather than copying) all the values from a ~vec. Therefore, I think it would be good if gained a function like: and, for convenience, something like this too: Is this proposal something desirable? If so I will try and submit code/docs/tests.
I merged 's change in
Change:
assert_eq!(a[&3], "three"); } <ins> #[test] fn test_zst() { let mut m = BTreeMap::new(); assert_eq!(m.len(), 0); assert_eq!(m.insert((), ()), None); assert_eq!(m.len(), 1); assert_eq!(m.insert((), ()), Some(())); assert_eq!(m.len(), 1); assert_eq!(m.iter().count(), 1); m.clear(); assert_eq!(m.len(), 0); for _ in 0..100 { m.insert((), ()); } assert_eq!(m.len(), 1); assert_eq!(m.iter().count(), 1); } // This test's only purpose is to ensure that zero-sized keys with nonsensical orderings // do not cause segfaults when used with zero-sized values. All other map behavior is // undefined. #[test] fn test_bad_zst() { use std::cmp::Ordering; struct Bad; impl PartialEq for Bad { fn eq(&self, _: &Self) -> bool { false } } impl Eq for Bad {} impl PartialOrd for Bad { fn partial_cmp(&self, _: &Self) -> Option<Ordering> { Some(Ordering::Less) } } impl Ord for Bad { fn cmp(&self, _: &Self) -> Ordering { Ordering::Less } } let mut m = BTreeMap::new(); for _ in 0..100 { m.insert(Bad, Bad); } } </ins> mod bench { use std::collections::BTreeMap; use std::__rand::{Rng, thread_rng};

Discussion:
Output:
The expansion of this is: Note that does not cause this problem.
Note also that this is only the case with jemalloc. The following runs successfully:
Actually, this is just related to calling jemalloc with 0 for the size:
We should probably apply a temporary fix for this (and audit all other uses of ), though will remove the direct allocation calls.
triage: I-nominated Seems pretty serious and something we may want to fix soon!
cc
I have a potential PR in progress, just running tests locally.
Change:
} let ty_generics = cx.tcx.generics_of(def_id); <ins> let num_where_predicates = hir_generics .predicates .iter() .filter(|predicate| predicate.in_where_clause()) .count(); </ins> let mut bound_count = 0; let mut lint_spans = Vec::new(); let mut where_lint_spans = Vec::new(); <del> let mut dropped_predicate_count = 0; let num_predicates = hir_generics.predicates.len(); </del> <ins> let mut dropped_where_predicate_count = 0; </ins> for (i, where_predicate) in hir_generics.predicates.iter().enumerate() { let (relevant_lifetimes, bounds, predicate_span, in_where_clause) = match where_predicate {

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Rustfix will fail to apply this: ` So we need to extend span to include the as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is in , with . The should be computed using in the loop, instead of crafting a specific computation. Likewise, should use method. If using those 2 methods from is not enough to solve the issue, those methods should perhaps be adapted.
claim
release-assignment Haven't been able to focus on this. Releasing assignment.
claim
Progress report: I'm working on it.
claim
Change:
} } <del> fn cvt_nz(error: libc::c_int) -> io::Result<()> { if error == 0 { Ok(()) } else { Err(io::Error::from_raw_os_error(error)) } } </del> unsafe { let mut attrs = MaybeUninit::uninit(); cvt_nz(libc::posix_spawnattr_init(attrs.as_mut_ptr()))?;

Discussion:
In libstd/sys/unix there are numerous cases where return code is checked for error using following pattern: That means, that error checking is performed only when compiled in non-optimized mode or after explicitly enabling debug assertions. This is a little bit worrying, especially when used on platforms where those functions can indeed fail and break safety.
(For anyone who was confused by the given example, pthreadmutexattrinit can fail with ENOMEM.)
On some platforms types like pthreadmutext, pthreadcondt, etc., are "fat" structures that have sufficient size to hold everything necessary and their initialization will never fail (unless initialized incorrectly). But on others they are opaque pointers to and require an additional memory allocation. Search for those typedefs in libc crate, gives a rough approximation of affected platforms. Sadly this also affects static mutexes, so even lock / unlock could potentially fail. Either way you could end up with a mutex which is not mutually exclusive at all.
When mutex initialization fails this leads to non-functioning mutex and unsoundness. The pthreadmutexlock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that. modify labels: C-bug I-unsound
Change:
swap_constraints(self); let locations = location.to_locations(); <ins> // Use location of promoted const in collected constraints for type_test in type_tests.iter() { let mut type_test = type_test.clone(); type_test.locations = locations; self.cx.borrowck_context.constraints.type_tests.push(type_test) } </ins> for constraint in constraints.outlives().iter() { let mut constraint = constraint.clone(); constraint.locations = locations;

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. --: (latest nightly as of today) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +F-inline_const
Note the missing bound. requires , and should throw a lifetime bounds error, but I think the inline const block is tripping something up. It works fine if you require or without the inline const block.
claim
Change:
// Store the pointer to closure data in an alloca for debug info because that's what the // llvm.dbg.declare intrinsic expects let env_pointer_alloca = if bcx.sess().opts.debuginfo == FullDebugInfo { <del> let alloc = alloc_ty(bcx, ty::mk_mut_ptr(bcx.tcx(), self_type), "__debuginfo_env_ptr"); </del> <ins> let alloc = alloca(bcx, val_ty(llenv), "__debuginfo_env_ptr"); </ins> Store(bcx, llenv, alloc); Some(alloc) } else {

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder
Change:
let post = format!(", consider renaming `{}` into `{snippet}`", suggestion.candidate); (span, snippet, post) } else { <del> (span, suggestion.candidate.to_string(), String::new()) </del> <ins> (span, suggestion.candidate.to_ident_string(), String::new()) </ins> }; let msg = match suggestion.target { SuggestionTarget::SimilarlyNamed => format!(

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

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. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </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 --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
.unwrap_or(false); let is_from = format!("{}", trait_ref.print_only_trait_path()) .starts_with("std::convert::From<"); <ins> let is_unsize = { Some(trait_ref.def_id()) == self.tcx.lang_items().unsize_trait() }; </ins> let (message, note) = if is_try && is_from { ( Some(format!(

Discussion:
I was playing with while I encountered a The simplest example I have producing the bug is Here is . It works if I remove the struct and put the directly in . The complete backtrace is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimised ()
claim
Change:
<ins> // This is a regression test for #69310, which was injected by #68118. // The issue here was that as a performance optimization, // we call the query `lit_to_const(input);`. // However, the literal `input.lit` would not be of the type expected by `input.ty`. // As a result, we immediately called `bug!(...)` instead of bubbling up the problem // so that it could be handled by the caller of `lit_to_const` (`ast_const_to_const`). fn main() {} const A: [(); 0.1] = [()]; //~ ERROR mismatched types const B: [(); b"a"] = [()]; //~ ERROR mismatched types </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and , but not on . <details<summaryNightly backtrace</summary</details
triage: P-high, assigning to self.
(This ended up being a great motivation for me to tie off some work I've been doing...)
ICE was introduced between nightly 2020-01-15 and 2010-01-16. Here are the merges from that time period: ( is independently working to identify which one is the culprit.)
Okay finished: searched nightlies: from nightly-2020-01-15 to nightly-2020-01-22 regressed nightly: nightly-2020-01-16 searched commits: from to regressed commit:
Looks like the problem was injected by PR
reassigning to
The following also causes an ICE: (Same reason, but different message.)
Fixed by
Change:
} } <del> Node::TypeBinding( TypeBinding { hir_id: binding_id, gen_args, kind, ident, .. }, ) if let Node::TraitRef(trait_ref) = tcx.hir().get_parent(*binding_id) </del> <ins> Node::TypeBinding(TypeBinding { hir_id: binding_id, gen_args, kind, ident, .. }) if let Node::TraitRef(trait_ref) = tcx.hir().get_parent(*binding_id) </ins> && let Some((idx, _)) = gen_args.args.iter().enumerate().find(|(_, arg)| { if let GenericArg::Const(ct) = arg {

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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 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: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe