jiebi/CodeConvo huggingface dataset:
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro] pub fn dance_like_you_want_to_ice(_: TokenStream) -> TokenStream { r#" impl Foo { type Bar = Box<()> + Baz; } "# .parse() .unwrap() } </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. --With a procmacro, an ICE occurs when generating an block (whether for a trait or not) that has an associated type that looks like this: The type needs to be a valid (in scope) type that takes a generic parameter, with a trait/lifetime bound. Both the generic parameter and the trait/lifetime bound don't actually need to be in scope - just syntactically valid. I only found this after a typo ( instead of ); this code shouldn't compile without the ICE anyway - the trait/lifetime bound is on a concrete type. As a result, I cannot foresee a situation where valid code that should compile would fail to compile as a result of this ICE. <!-- 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. --Occurs on latest stable, beta and nightly versions. : I have also tested this on a host running , and the ICE also occurs on that machine as well. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing .
Change:
<ins> // Regression test for ICE #122989 trait Foo<const N: Bar<2>> { //~^ WARN trait objects without an explicit `dyn` are deprecated //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! //~| ERROR cycle detected when computing type of `Foo::N` //~| ERROR cycle detected when computing type of `Foo::N` //~| ERROR the trait `Foo` cannot be made into an object //~| ERROR the trait `Foo` cannot be made into an object //~| ERROR the trait `Foo` cannot be made into an object //~| ERROR `(dyn Bar<2> + 'static)` is forbidden as the type of a const generic parameter fn func() { } } trait Bar<const M: Foo<2>> {} //~^ WARN trait objects without an explicit `dyn` are deprecated //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! //~| ERROR the trait `Foo` cannot be made into an object //~| ERROR `(dyn Foo<2> + 'static)` is forbidden as the type of a const generic parameter fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:35 ~ [f939]::N).1), defid: DefId(0:37 ~ [f939]::N::{constant}), body: BodyId { hirid: HirId(DefId(0:35 ~ [f939]::N).2) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:35 ~ [f939]::N).1), defid: DefId(0:37 ~ [f939]::N::{constant}), body: BodyId { hirid: HirId(DefId(0:35 ~ [f939]::N).2) } })' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [paramenv] computing normalized predicates of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
bisects to
Slightly smaller:
Change:
print-type-size         field `.0`: 12 bytes print-type-size     variant `None`: 0 bytes print-type-size type: `EmbeddedDiscr`: 8 bytes, alignment: 4 bytes <ins> print-type-size     discriminant: 1 bytes </ins> print-type-size     variant `Record`: 7 bytes <del> print-type-size         field `.val`: 4 bytes print-type-size         field `.post`: 2 bytes </del> print-type-size         field `.pre`: 1 bytes <ins> print-type-size         field `.post`: 2 bytes print-type-size         field `.val`: 4 bytes </ins> print-type-size     variant `None`: 0 bytes <del> print-type-size     end padding: 1 bytes </del> print-type-size type: `MyOption<Union1<std::num::NonZeroU32>>`: 8 bytes, alignment: 4 bytes print-type-size     discriminant: 4 bytes print-type-size     variant `Some`: 4 bytes

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
<ins> error[E0283]: type annotations needed --> $DIR/issue-34979.rs:6:13 | LL | trait Foo {} | --------- required by this bound in `Foo` ... LL |     &'a (): Foo, |             ^^^ cannot infer type for reference `&'a ()` | = note: cannot satisfy `&'a (): Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>

Discussion:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.
Change:
pub fn allow_internal_unstable<'a>( sess: &'a Session, <del> attrs: &[Attribute], </del> <ins> attrs: &'a [Attribute], </ins> ) -> Option<impl Iterator<Item = Symbol> + 'a> { <del> let attr = sess.find_by_name(attrs, sym::allow_internal_unstable)?; let list = attr.meta_item_list().or_else(|| { sess.diagnostic() .span_err(attr.span, "allow_internal_unstable expects list of feature names"); None })?; </del> <ins> let attrs = sess.filter_by_name(attrs, sym::allow_internal_unstable); let list = attrs .filter_map(move |attr| { attr.meta_item_list().or_else(|| { sess.diagnostic().span_err( attr.span, "`allow_internal_unstable` expects a list of feature names", ); None }) }) .flatten(); </ins> Some(list.into_iter().filter_map(move |it| { let name = it.ident().map(|ident| ident.name); if name.is_none() {

Discussion:
Discussed in zulip: https://rust- The problem is that compiler doesn't accept code like this: But it accepts code when merging mutiple annotations into one: : Version 1.48.0-nightly ( 2020-09-22) cc which modified some const stability checks. modify labels: E-mentor
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
just refactored a few individual calls to into a single helper function. only looks for the first attribute it seems. Shouldn't be hard to fix.
assign
Error: Parsing assign command in failed: ...'n bugadani' ''... Please let know if you're having trouble with this bot.
The PR did not actually fix the issue. The test case to the PR also works without the PR. A test case that would fail would actually check whether a second attribute would be honored. Adding a second attribute was silently ignored, and it still is after the PR. Edit: nevermind, all is good:
It doesn't hurt to double check, just takes some time :)
Change:
#[no_mangle] pub fn a(exp: u32) -> u64 { // CHECK: %{{[^ ]+}} = icmp ugt i32 %exp, 64 <del> // CHECK: %{{[^ ]+}} = zext i32 %exp to i64 </del> <ins> // CHECK: %{{[^ ]+}} = zext{{( nneg)?}} i32 %exp to i64 </ins> // CHECK: %{{[^ ]+}} = shl nuw i64 {{[^ ]+}}, %{{[^ ]+}} // CHECK: ret i64 %{{[^ ]+}} 2u64.pow(exp)

Discussion:
Seems like the updated test expectations don't quite match up with LLVM 18, first failing check is: Found over at our experimental rust + LLVM @ HEAD build bot: Looks like LLVM 18 adds some extra -s, testing a PR to fix this:
label: +A-LLVM
Change:
} else { out.push_str(line); } <del> if iter.peek().is_some() { out.push('n'); } } if frag.need_backline { </del> out.push('n'); } }

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
/// assert_eq!(None.unwrap_or_else(|| 2 * k), 20); /// ``` #[inline] <ins> #[track_caller] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn unwrap_or_else<F>(self, f: F) -> T where

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 the panic to be reported at line 2 Instead, it still was reported at line 7. I also tried. but this reported as an error in core I was able to work around the issue with code like this: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The core problem here is that is effectively part of the ABI, so when you have a function like , you'd have to somehow know whether it is trackcaller or not -- this would have to be to the type explicitly. Currently it is just never made track_caller. There's no easy fix here that I can see, this requires a language extension.
Oh looks like that language design work was already done: So on nightly, this works: The only piece missing is adding to , which is a trivial PR.
claim
Change:
<ins> // Copyright 2014 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. trait Foo { fn bar(&mut self, other: &mut Foo); } struct Baz; impl Foo for Baz { fn bar(&mut self, other: &Foo) {} //~^ ERROR method `bar` has an incompatible type for trait: values differ in mutability [E0053] } fn main() {} </ins>

Discussion:
Code sample: Backtrace and debug log:
Similar code without the feature does not cause a compiler error:
A smaller test case:
Neither of the test cases are ICEing for me today, I'm seeing the following:
Flagging as needstest

The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)
Change:
WriteAndRead, // x += y } <del> #[derive(Copy, Clone)] enum OverloadedCallType { FnOverloadedCall, FnMutOverloadedCall, FnOnceOverloadedCall, } impl OverloadedCallType { fn from_trait_id(tcx: TyCtxt<'_>, trait_id: DefId) -> OverloadedCallType { for &(maybe_function_trait, overloaded_call_type) in &[ (tcx.lang_items().fn_once_trait(), FnOnceOverloadedCall), (tcx.lang_items().fn_mut_trait(), FnMutOverloadedCall), (tcx.lang_items().fn_trait(), FnOverloadedCall), ] { match maybe_function_trait { Some(function_trait) if function_trait == trait_id => return overloaded_call_type, _ => continue, } } bug!("overloaded call didn't map to known function trait") } fn from_method_id(tcx: TyCtxt<'_>, method_id: DefId) -> OverloadedCallType { let method = tcx.associated_item(method_id); OverloadedCallType::from_trait_id(tcx, method.container.id()) } } </del> /////////////////////////////////////////////////////////////////////////// // The ExprUseVisitor type //

Discussion:
Problematic code: Minimal reproduction: This ICE happens on both nightly and stable. rustc 1.42.0-nightly ( 2020-01-06) binary: rustc commit-hash: commit-date: 2020-01-06 host: x86_64-unknown-linux-gnu release: 1.42.0-nightly LLVM version: 9.0 Backtrace:
I'm not sure how to reproduce the ICE given the two snippets at the top. Can you clarify the minimal reproduction: how do I reproduce it in the playground?
Simplified:
The failure occurs here: I guess we can add to first arm (), is it safe?
triage: P-high. Removing I-nominated label.
Change:
target: Vec<String>, cargo: Option<String>, rustc: Option<String>, <ins> rustfmt: Option<String>, /* allow bootstrap.py to use rustfmt key */ </ins> docs: Option<bool>, compiler_docs: Option<bool>, submodules: Option<bool>,

Discussion:
with the introduction of , the mandatories the use of downloaded . but all platforms doesn't have binary distribution, mainly tiers-3 platforms like OpenBSD. For rustc or cargo dependencies, it is possible to use (with and key in section) to point to alternate binaries. this way, doesn't download them and use local supplied binaries. For it is currently not possible: if is able to deal with it, will complains that isn't a valid key: What would be the right way to use a local binary in order to copte with , and not force the use of downloaded binary ? Would adding a key in section of would be accepted (I could provide a patch of it, if yes) ? or should another method used ? Cc
Yes, that was on oversight on my part. I would be happy to review a patch adding it to You should also be able to comment out the line in as a (possibly) temporary fix, this is my plan for beta and stable branches FWIW.
Change:
<ins> error: format argument must be a string literal --> $DIR/format-empty-block-unit-tuple-suggestion-130170.rs:5:14 | LL |     println!({}, "sss", s); |              ^^ | help: you might be missing a string literal to format with | LL |     println!("{:?} {} {}", {}, "sss", s); |              +++++++++++++ error: format argument must be a string literal --> $DIR/format-empty-block-unit-tuple-suggestion-130170.rs:7:14 | LL |     println!({}); |              ^^ | help: you might be missing a string literal to format with | LL |     println!("{:?}", {}); |              +++++++ error: format argument must be a string literal --> $DIR/format-empty-block-unit-tuple-suggestion-130170.rs:9:14 | LL |     println!(s, "sss", s, {}); |              ^ | help: you might be missing a string literal to format with | LL |     println!("{} {} {} {:?}", s, "sss", s, {}); |              ++++++++++++++++ error: format argument must be a string literal --> $DIR/format-empty-block-unit-tuple-suggestion-130170.rs:11:14 | LL |     println!((), s, {}); |              ^^ | help: you might be missing a string literal to format with | LL |     println!("{:?} {} {:?}", (), s, {}); |              +++++++++++++++ error: aborting due to 4 previous errors </ins>

Discussion:
Cargo does not seem to be detecting the {} outside brackets and provides an incredibly strange fix instead. No response the file is from here: You will need serdejson crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
it's worth noting that is a valid rust expression, it evaluates to the empty tuple. this is perfectly valid code: minimal repro:
huh, didn't know that. good to know ig
I think it is worth special casing this in diagnostics though, if someone wanted to print a unit type (for some reason?) they probably should use the value or just embed it directly in the format string. An empty expression as the first argument of a format macro is almost certainly a mistake.
claim
The PR that closed this doesn't seem to actually apply the wanted fix, this should be reopened.
Hello, thank you very much for the suggestion. My idea is to find a slightly more general solution instead of special treatment for rare cases. If you think it should be modified as , I completely agree with reopening the issue. :relaxed:
Change:
<del> running 2 tests test $DIR/doctest-output.rs - (line 5) ... ok test $DIR/doctest-output.rs - foo::bar (line 11) ... ok </del> <ins> running 3 tests test $DIR/doctest-output.rs - (line 7) ... ok test $DIR/doctest-output.rs - ExpandedStruct (line 23) ... ok test $DIR/doctest-output.rs - foo::bar (line 17) ... ok </ins> <del> test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out </del> <ins> test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out </ins>

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
} } <ins> fn assoc_item_in_trait_impl(cx: &LateContext<'_>, ii: &hir::ImplItem<'_>) -> bool { let item = cx.tcx.associated_item(ii.owner_id); item.trait_item_def_id.is_some() } </ins> declare_lint! { /// The `non_camel_case_types` lint detects types, variants, traits and /// type parameters that don't have camel case names.

Discussion:
I believe the old behavior from nightly-2023-04-19 is correct. The repro has nothing to do with trait impls so I believe was not supposed to have affected it.
Bisects to .
How on earth did that happen? It was like a five-line change. :laughing: EDIT: got a fix, will post soon.
Probably something to do with the hygeine of the span on the versus the . if you can't fix this then ping me and I'll look at it, but we probably should fix it sooner than later.
Actually, you're probably right.
Oh, no, that's not it. You're missing a call to in the visitor.
Change:
"test/bench/shootout-chameneos-redux.rs", # BSD "test/bench/shootout-fannkuch-redux.rs", # BSD "test/bench/shootout-fasta.rs", # BSD <ins> "test/bench/shootout-fasta-redux.rs", # BSD </ins> "test/bench/shootout-k-nucleotide.rs", # BSD "test/bench/shootout-mandelbrot.rs", # BSD "test/bench/shootout-meteor.rs", # BSD

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (except artifacts as empty lines): OK waiting for response OK (MoCo employee) OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
ping
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Change:
return None; } <del> // FIXME we need to revisit this for #67176 if rvalue.needs_subst() { return None; } </del> // Perform any special handling for specific Rvalue types. // Generally, checks here fall into one of two categories: //   1. Additional checking to provide useful lints to the user

Discussion:
The lint should fire on the following code, but it does not: (This testcase now exists in-tree as a FIXME in .) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take this. claim
I have some plans to follow-up on with some cleanup. That might at least partially resolve this issue here. So it's probably best to wait until after that is done.
All right, landed, so what I planned here is done. The remaining issue is about associated consts. The issue there is that fails, or maybe we are hitting an , but I have not tried further. The issue is all yours, :)
Great! I'll start investigating.
Never mind, that one is already fixed on beta.
got reverted in , so we have to reopen this.