jiebi/CodeConvo huggingface dataset:
Change:
self.data.get_mut(&id.local_id) } <ins> pub fn get(&mut self, id: hir::HirId) -> Option<&V> { validate_hir_id_for_typeck_results(self.hir_owner, id); self.data.get(&id.local_id) } </ins> pub fn entry(&mut self, id: hir::HirId) -> Entry<'_, hir::ItemLocalId, V> { validate_hir_id_for_typeck_results(self.hir_owner, id); self.data.entry(id.local_id)

Discussion:
It's underlining the wrong argument. No response No response
I'm getting an entirely different and much more helpful error:
Are you sure you minimized the code correctly? Not sure how to repro the example you shared,
Arf, sorry about that... Also important to note, I'm using: I pushed the code with this issue . However it requires a mac to enter this code. Just running is enough to trigger it.
This should be re-minimized by someone who has a Mac then. label +E-needs-mcve
Minimization: Note that: in all cases (including when I ran the original code), there is now a more sensible type error, and the unsized local error is not actually pointing at the wrong thing, it's talking about the type of the part of the tuple unrelated to the if/else type mismatch. It seems like the type mismatch is causing the compiler to fail to properly perform the deref coercion of the , even though it's not the part of the tuple that has the type mismatch. Tested on versions:
label -E-needs-mcve
Change:
impl<T: ?Sized> !Send for ReentrantLockGuard<'_, T> {} #[unstable(feature = "reentrant_lock", issue = "121440")] <ins> unsafe impl<T: ?Sized + Sync> Sync for ReentrantLockGuard<'_, T> {} #[unstable(feature = "reentrant_lock", issue = "121440")] </ins> impl<T> ReentrantLock<T> { /// Creates a new re-entrant lock in an unlocked state ready for use. ///

Discussion:
I tried running this code in miri: I expected to see this happen: compile error Instead, this happened: compiled successfully and miri reported a data race this is because the automatic is incorrect: 'a,+T%3E ReentrantLock's tracking issue:
label I-unsound
label requires-nightly
Change:
// so add an empty section. if file.format() == object::BinaryFormat::Coff { file.add_section(Vec::new(), ".text".into(), object::SectionKind::Text); <ins> // We handle the name decoration of COFF targets in `symbol_export.rs`, so disable the // default mangler in `object` crate. file.set_mangling(object::write::Mangling::None); // Add feature flags to the object file. On MSVC this is optional but LLD will complain if // not present. let mut feature = 0; if file.architecture() == object::Architecture::I386 { // Indicate that all SEH handlers are registered in .sxdata section. // We don't have generate any code, so we don't need .sxdata section but LLD still // expects us to set this bit (see #96498). // Reference: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format feature |= 1; } file.add_symbol(object::write::Symbol { name: "@feat.00".into(), value: feature, size: 0, kind: object::SymbolKind::Data, scope: object::SymbolScope::Compilation, weak: false, section: object::write::SymbolSection::Absolute, flags: object::SymbolFlags::None, }); </ins> } for (sym, kind) in symbols.iter() {

Discussion:
I tried this code: Build with With recent nighties it fails to link: This issue does not occur with or . searched nightlies: from nightly-2022-04-24 to nightly-2022-04-28 regressed nightly: nightly-2022-04-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
cc This may potentially be reproducible with too. UPD: It does reproduce on , even on hello-world, if LLD is used as a linker instead of UPD2: needs to have one additional "feature-enabling" symbol on these targets, see in LLD sources.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Thanks for the quick fix!
Change:
pub(crate) fn mir_generator_witnesses<'tcx>( tcx: TyCtxt<'tcx>, def_id: LocalDefId, <del> ) -> GeneratorLayout<'tcx> { </del> <ins> ) -> Option<GeneratorLayout<'tcx>> { </ins> assert!(tcx.sess.opts.unstable_opts.drop_tracking_mir); let (body, _) = tcx.mir_promoted(def_id);

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 cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic
Change:
found); } Err(err) => { <del> let err_description = err.description(); let found = match count_expr.node { </del> <ins> let err_msg = match count_expr.node { </ins> ast::ExprPath(None, ast::Path { global: false, ref segments, .. }) if segments.len() == 1 => <del> format!("{}", "found variable"), _ => format!("but {}", err_description), </del> <ins> format!("found variable"), _ => match err.kind { ErrKind::MiscCatchAll => format!("but found {}", err.description()), _ => format!("but {}", err.description()) } </ins> }; span_err!(self.sess, count_expr.span, E0307, <del> "expected constant integer for repeat count, {}", found); </del> <ins> "expected constant integer for repeat count, {}", err_msg); </ins> } } 0

Discussion:
The message "expected constant integer for repeat count, but unsupported constant expr" is a bit weird (ungrammatical?).
Change:
<del> Subproject commit 2d6d73fafe2f087354f7cea37297cd81316cae98 </del> <ins> Subproject commit c2a2e25d0b050d70d6a355f9b7545a991fc8783a </ins>

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! And nominating for compiler team prioritization.
The bot is wrong; it's not that broke Miri, it's
Change:
/// ``` /// /// [`as_ptr`]: #method.as_ptr <del> #[unstable(feature = "slice_ptr_range", issue = "65807")] </del> <ins> #[stable(feature = "slice_ptr_range", since = "1.48.0")] </ins> #[rustc_const_unstable(feature = "const_ptr_offset", issue = "71499")] #[inline] pub const fn as_ptr_range(&self) -> Range<*const T> {

Discussion:
Tracking issue for by See
Anything holding up stabilization on this? I'd like to be able to use this to check if two slices overlap, as pointers implement . It seems like a simple API that doesn't have a ton of complexity to it.
Note that with these functions can be made . The stabilization of these methods as can just be tracked as part of .
Thanks! PR: .
Change:
// Creates a new module which looks like: // <ins> //      #[doc(hidden)] </ins> //      mod $gensym { //          extern crate proc_macro; //

Discussion:
crates, when compiled with , generate invalid warnings about missing documentation. The following simple crate demonstrates the error. : : I expect this to compile cleanly since there is a crate-level doc comment and a doc comment for the public function. Instead, compiling gives: which makes no sense since line 1 is a comment. Compiler version - latest stable, but fails on yesterday's nightly (2017-05-14) too: :
cc (tracking issue)
I am hitting the same problem. This issue is preventing for proc-macro crates (I haven't found a work around). That's pretty annoying :-/ Rust 1.24.1.
Same here. Is there a fix for this?
Seems to still be happening.
Fails on stable, beta, and nightly still.
On a proc-macro crate in , I'm getting two warnings: and with no line numbers.
shows that the compiler is inserting a with a . I didn't find the code that does the insertion in a very brief search.
So I guess the low-effort fix here is slapping on that ? EDIT: Looks like the code that generates that is ?
Thanks Turns out my working copy wasn't updated like I thought so searching through it didn't work. PR just submitted.
Change:
ty::ConstKind::Infer(InferConst::Fresh(_)) => { bug!("Unexpected const in full const resolver: {:?}", c); } <ins> ty::ConstKind::Infer(InferConst::EffectVar(evid)) => { return Err(FixupError::UnresolvedEffect(evid)); } </ins> _ => {} } c.try_super_fold_with(self)

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:
run_test(|a| panic_after_init_temp(a)); run_test(|a| panic_after_init_by_loop(a)); <ins> run_test(|a| bindings_after_at_dynamic_init_move(a, true)); run_test(|a| bindings_after_at_dynamic_init_move(a, false)); run_test(|a| bindings_after_at_dynamic_init_ref(a, true)); run_test(|a| bindings_after_at_dynamic_init_ref(a, false)); run_test(|a| bindings_after_at_dynamic_drop_move(a, true)); run_test(|a| bindings_after_at_dynamic_drop_move(a, false)); run_test(|a| bindings_after_at_dynamic_drop_ref(a, true)); run_test(|a| bindings_after_at_dynamic_drop_ref(a, false)); </ins> run_test_nopanic(|a| union1(a)); }

Discussion:
The feature which allows for patterns, is implemented in The PR doesn't have as good coverage of the dynamic semantics as we might like. Once the PR lands, we should try to improve things before we stabilize the feature. Notable tests to include: [x] Dynamic drop () cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is now unblocked as has landed.
I would like to work on this one
Go for it :) assign
Now that has landed, I think we can close this once also lands.
Change:
<ins> // compile-pass // compile-flags: -Z unpretty=hir #![feature(existential_type)] #[prelude_import] use ::std::prelude::v1::*; #[macro_use] extern crate std; trait Animal { } fn main() { pub existential type ServeFut : Animal; } </ins>

Discussion:
expanded with yields we should not print that extra
Hi, I will like to work on this issue.
awesome! Most likely all that is required is to remove you can check if there's a test in that has a comment with in it. If there is, just add the above test line to it and run tests with . If there is no such test, add such a test ;)
I think I fixed this in one of my PRs, but not sure when it will merge, so go for it. :-)
While adding test, I am getting following error message: The existing test can be seen here:
you need to add to the test
Added that, many thanks!
Change:
<ins> error[E0277]: the trait bound `u8: Identity` is not satisfied --> $DIR/projection-as-union-type-error.rs:12:9 | LL |     a:  <Foo as Identity>::Identity, |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Identity` is not implemented for `u8` | help: this trait has no implementations, consider adding one --> $DIR/projection-as-union-type-error.rs:5:1 | LL | pub trait Identity { | ^^^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </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. --: Regression in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Considering this errors with rustc, and rustdoc can only document rust code that actually compiles, I'd say this is in the same bucket as the other issues we have open about this, meaning "not a bug, just a papercut"?
this is not true
I can only document code that compiles, ignoring method bodies. This specific test has no method bodies, so does it fall under that rule?
That seems possible, but you should test to make sure. Rustdoc's logic around this is extremely janky and indirect.
What is the benefit of documenting code that does not compile?
I can't keep having this argument. Please read the documentation.
cc
Triage: No longer ICEs. Might need regression test, not sure. Current compiler output:
Change:
summaries = [] def summarise(fname): summary = {} <del> fd = open(fname) for line in fd: status, test = line.strip().split(' ', 1) if not summary.has_key(status): summary[status] = [] summary[status].append(test) summaries.append((fname, summary)) </del> <ins> with open(fname) as fd: for line in fd: splitline = line.strip().split(' ') if len(splitline) == 1: continue status = splitline[0] test = splitline[-1] # track bench runs if splitline[1] == 'ns/iter': status = 'bench' if not summary.has_key(status): summary[status] = [] summary[status].append(test) summaries.append((fname, summary)) </ins> def count(t): return sum(map(lambda (f, s): len(s.get(t, [])), summaries)) logfiles = sys.argv[1:]

Discussion:
The final summary at the end says we ran 28 tests when we ran thousands.
Interesting, is the code for buildbot in src/test?
This code is part of the build system. is the place to start looking. The code for recording the number of tests is probably in .
Thanks brson, You were right, the code is in extra::test. Do I execute the tests through:
I'll pick this up, unless it's still in-progress or has been fixed already.
Go for it, I'd love to see what you come up with!
Change:
test_abi_compatible!(wrap1, $t, Wrapper1<$t>); test_abi_compatible!(wrap2, $t, Wrapper2<$t>); test_abi_compatible!(wrap3, $t, Wrapper3<$t>); <del> #[cfg(not(any(target_arch = "riscv64", target_arch = "loongarch64")))] </del> <ins> #[cfg(not(target_arch = "loongarch64"))] </ins> test_abi_compatible!(wrap4, $t, WrapperUnion<$t>); } };

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is Not sure whom to ping for RISC-V issues.
I think the fix will have to be to treat repr(transparent) unions specially somewhere around here
Cc
I'm afraid that the semantics of on unions are not clearly defined enough to figure out exactly how they should be specially treated (which variant should be used? etc.). Can you ping other people who have more knowledge on this? (If on unions turns out to be incompatible with ABIs that have content destructuring semantics that depends on the types of the field in the (e.g. the RISC-V C psABI) then we definitely have a bigger problem.)
I have no idea who would know anything about RISC-V calling conventions. :shrug: and no other ABI is failing this test. Basically, when the ABI description says "unions do X", then this should only apply to repr(C) and repr(Rust) unions. A repr(transparent) union must be treated exactly like its non-ZST field.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I haven't seen the Rust representation before - is the example saying that is splitting the values into float and integer registers and passing them, whereas is treating the whole thing as an bigger opaque integer? If so then based on section 18.2 here, I think the first one would be correct, assuming Rust doesn't ever make its tuples opaque helped me with something RISC-V at some point so may know where to look. Or deferring to clang
I honestly don't know what that means, it is sadly mostly undocumented. But I know it must be the same for the types to be ABI-compatible. has been opened to fix this issue.
now that this is fixed, is there a CI test to catch regressions?
There is a test in  but we don't run tests for riscv, since it's a tier 2 target.
Also see for another ABI issue that affects riscv (and more).
Are tier 2 tests run once before release or anything like that? It seems like at least a subset of tests (this one) are important enough that we should raise a red flag if we brake them somehow on any targets.

But that doesn't fit well into the tiering structure...
I'm not aware of any process like that. Part of the point of being tier 2 is not to burden all contributors with keeping the target working, is it? If we do want to accept that burden, we could consider running something like for tier 2 targets. But having this discussion in a closed issue makes little sense. Do you want to open a new issue or Zulip thread for discussing tier 2 target test coverage?
Inspired by I found a way to have a test for this:
Awesome! Thanks for the update here
Change:
= help: add #![feature(generic_associated_types)] to the crate attributes to enable error[E0658]: generic associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:25:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:26:5 </ins> | LL |     type Pointer2<u32> = Box<u32>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
Compiling this code results in no output by . But exits with 101 and does not produce any artifacts. () The error happens with: , , and -
If I set breakpoints on - It hits the first two but not the third, seemingly pointing to returning an .
The silent exit is a regression. From godbolt, #### 1.23.0 exit code = 101 #### 1.24.0–1.25.0 exit code = 101 #### 1.26.0–1.28.0(beta) No message, exit code = 101 #### 1.29.0(nightly) No message, exit code = 1
cc -- it'd be good to find out why we stopped providing any output at all here
I'm worried it might be one of my parser changes to provide better diagnostics... I would probably check for any odd looking .
It's not the parsing itself, it's that in 1.24 the feature was introduced:
do you think you see what the problem is?
Calling P-high but we don't yet have an obvious assignee. Still, seems bad that there is no diagnostic output at all! Not a good look.
The core issue is reported in However, the example here also demonstrates that clauses aren't being feature gated properly.
I've made to address the surface problem, which is that you can trigger this on stable, without declaring the feature. I thought it was better to fix that part of the problem straight away.
Narrowing it down a little more: is at this point when the clauses are defined, so something's going wrong before that point.
Change:
<ins> error: expected `;`, found `}` --> $DIR/issue-87635.rs:4:17 | LL |     pub fn bar() |                 ^ help: add `;` here ... LL | } | - unexpected token error: associated function in `impl` without body --> $DIR/issue-87635.rs:4:5 | LL |     pub fn bar() |     ^^^^^^^^^^^- |                | |                help: provide a definition for the function: `{ <body> }` error: aborting due to 2 previous errors </ins>

Discussion:
Playground with repro . Not present in latest stable or beta. <!-- 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
Regressed since , I think is the cause.
right, this issue can be probably be closed as duplicate of
I would suggest not closing this issue as long as literally starts with the statement referencing back to this issue. Furthermore, this issue is older, so if they’d be duplicates, would be closed.
Change:
<ins> use std::sync::Arc; macro_rules! GenT { ($name:tt) => { #[derive(Default, Debug)] struct $name { #[allow(unused)] val: i32, } impl $name { #[allow(unused)] fn new(val: i32) -> Self { $name { val } } } }; } GenT!(T1); GenT!(T2); GenT!(T3); GenT!(T4); GenT!(T5); GenT!(T6); GenT!(T7); GenT!(T8); #[allow(unused)] fn foo(p1: T1, p2: Arc<T2>, p3: T3, p4: Arc<T4>, p5: T5, p6: T6, p7: T7, p8: Arc<T8>) {} fn three_diff(_a: T1, _b: T2, _c: T3) {} fn four_shuffle(_a: T1, _b: T2, _c: T3, _d: T4) {} fn main() { three_diff(T2::new(0)); //~ ERROR this function takes four_shuffle(T3::default(), T4::default(), T1::default(), T2::default()); //~ ERROR 35:5: 35:17: arguments to this function are incorrect [E0308] four_shuffle(T3::default(), T2::default(), T1::default(), T3::default()); //~ ERROR 36:5: 36:17: arguments to this function are incorrect [E0308] let p1 = T1::new(0); let p2 = Arc::new(T2::new(0)); let p3 = T3::new(0); let p4 = Arc::new(T4::new(1)); let p5 = T5::new(0); let p6 = T6::new(0); let p7 = T7::new(0); let p8 = Arc::default(); foo( //~^ 47:5: 47:8: this function takes 8 arguments but 7 arguments were supplied [E0061] p1, //p2, p3, p4, p5, p6, p7, p8, ); } </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: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
<ins> error[E0700]: hidden type for `impl PlusOne` captures lifetime that does not appear in bounds --> $DIR/imply_bounds_from_bounds_param.rs:24:5 | LL | fn test<'a>(y: &'a mut i32) -> impl PlusOne { |         -- hidden type `<&'a mut i32 as Callable>::Output` captures the lifetime `'a` as defined here LL |     <&'a mut i32 as Callable>::call(y) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | help: to declare that `impl PlusOne` captures `'a`, you can add an explicit `'a` lifetime bound | LL | fn test<'a>(y: &'a mut i32) -> impl PlusOne + 'a { |                                             ++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0700`. </ins>

Discussion:
This code should pass but it doesn't: This is resurrected. Cc label F-typealiasimpl_trait C-bug T-compiler T-types
Oh heh, I fixed the situation for registering the hidden type but didn't allow implying anything from that.