jiebi/CodeConvo huggingface dataset:
Change:
use crate::ty::{GenericArg, GenericArgKind, SubstsRef}; use rustc_hir as ast; use rustc_hir::def_id::DefId; <del> use rustc_span::DUMMY_SP; </del> use rustc_target::spec::abi; use std::iter;

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</detailsThis occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
syntax_pos = { path = "../libsyntax_pos" } backtrace = "0.3.3" parking_lot = "0.9" <del> byteorder = { version = "1.1", features = ["i128"]} </del> <ins> byteorder = { version = "1.3" } </ins> chalk-engine = { version = "0.9.0", default-features=false } rustc_fs_util = { path = "../librustc_fs_util" } smallvec = { version = "0.6.7", features = ["union", "may_dangle"] }

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! cc the PR reviewer, and -- nominating for prioritization.
triage: P-medium. Unnominating.
Change:
LinkOutputKind::StaticNoPicExe => { // `-static` works for both gcc wrapper and ld. self.cmd.arg("-static"); <del> if !self.is_ld { </del> <ins> if !self.is_ld && self.sess.target.target.options.linker_is_gnu { </ins> self.cmd.arg("-no-pie"); } }

Discussion:
between and linking behavior changes which broke my cross compilation from linux to macos. It now adds the which is unknown by my compiler. leaving it out would probably fix the error. Below are detailed informations about my project and the cross compilation setup in order to reproduce. We for the veloren project we have a CI docker container. i tried to update the toolchain. with docker the error is reproduceable quite easy, however if you are familar with docker you can skip some steps in order to save you a hour of compilation I expected to see this happen: we successfully build the osxcross enviorment with the first docker container, based on this: the code compiles for macos after compilation it starts linking using the '/dockercache/osxcross/target/bin/x86_64-apple-darwin17-clang' linker we build in osxcross the linking suceeds Instead, this happened: the linking fails as it tries to use a flag which isn't supported. Interestingly when you search in the rust code for this flag, you'll find a refactor about a month ago changing behavior here: however i personally dont know how that caused the change. :
This is a regression from
Looks like the condition was lost, and clang for macos is apparently not "linkerisgnu".
I'll fix this today.
Assigning .
Fixed in
awesome, i will confirm it, once it's in a good nightly build :)
Just wanted to confirm that with this error no longer occurs, so it is fixed now, thank you!
Change:
res: Res, qpath: &hir::QPath, subpats: &'tcx [P<Pat>], <del> fields: &[ty::FieldDef], expected: Ty<'tcx> </del> <ins> fields: &'tcx [ty::FieldDef], expected: Ty<'tcx>, had_err: bool, </ins> ) { let subpats_ending = pluralize!(subpats.len()); let fields_ending = pluralize!(fields.len());

Discussion:
Source code:
Please provide the source code needed to reproduce this (or preferably a reduced version of that)
Sourced code provided at the end of the document. I'm willing to provide more info if needed.
Reconstructed from first principles:
The problem occurs here:
triage: has PR. P-high, removing nomination.
Change:
<ins> // Regression test for #85945: Don't suggest `?Sized` bound if an explicit // `Sized` bound is already in a `where` clause. fn foo<T>(_: &T) where T: Sized {} fn bar() { foo(""); } //~^ERROR the size for values of type pub fn main() { } </ins>

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Change:
} } <ins> #[stable(feature = "box_slice_clone", since = "1.3.0")] impl Clone for Box<str> { fn clone(&self) -> Self { let len = self.len(); let buf = RawVec::with_capacity(len); unsafe { ptr::copy_nonoverlapping(self.as_ptr(), buf.ptr(), len); mem::transmute(buf.into_box()) // bytes to str ~magic } } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<T: ?Sized + PartialEq> PartialEq for Box<T> { #[inline]

Discussion:
Just like , Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple ptr::copy of the data. Follow up after
Change:
37|      0|            countdown = 10; 38|      0|        } 39|      0|        "alt string 2".to_owned() <del> 40|      1|    }; </del> <ins> 40|      0|    }; </ins> 41|      1|    println!( 42|      1|        "The string or alt: {}" 43|      1|        ,

Discussion:
I expect something that looks like the result, for a similar (non-macro) closure: But instead we get results like the following: This issue is demonstrated in the coverage results from the test: I have a new PR in progress to show more examples, and those examples expose the fact that the coverage for is actually being to the macro's source itself. Note that there were 5 macro calls with missing coverage in the corresponding test case, and the coverage report shows 5 . So all are taken into account. Nevertheless, this is a function-like macro, and it should behave like a function call, and show the coverage at the calling site.
I suspect the problem is related to how the expansion is handled for the macro body. When defined without braces, it is (likely) "de-sugared" (adding braces perhaps?) in a way that confuses the macro expansion handling in .
+A-code-coverage fyi:
I looked into this (reviewing debug logs) and the issue it not exactly a macro problem, I think. The closure tests I used all call , and that macro is defined as follows: Note the expansion starts with . That creates a closure that looks like it starts: Since the opening brace comes from the macro, the closure MIR body source starts within the macro. Generating the coverage relative to the source that contains the first character of the function body is generally reasonable, and even in this case it might be hard to argue that it's wrong. But it's probably not right either. The issue is, where should coverage be generated? If the macro is more complex, instrumenting the macro is good. If the caller (which could be another macro, by the way) is more complex, instrumenting the caller source is often better. For example, intuitively we want the coverage results of the two macros below to look similar. Putting the coverage results in the source for the macro loses a lot of coverage span detail! I'm not exactly sure what to do. I'm thinking of treating closures (at least closures that start with a macro) as a special case (at least, when coverage is enabled), and find some way of handling the body span as if it included its own block braces.
Change:
}); // #73631: closures inherit `#[target_feature]` annotations <del> if tcx.features().target_feature_11 && tcx.is_closure(did.to_def_id()) { </del> <ins> // // If this closure is marked `#[inline(always)]`, simply skip adding `#[target_feature]`. // // At this point, `unsafe` has already been checked and `#[target_feature]` only affects codegen. // Emitting both `#[inline(always)]` and `#[target_feature]` can potentially result in an // ICE, because LLVM errors when the function fails to be inlined due to a target feature // mismatch. // // Using `#[inline(always)]` implies that this closure will most likely be inlined into // its parent function, which effectively inherits the features anyway. Boxing this closure // would result in this closure being compiled without the inherited target features, but this // is probably a poor usage of `#[inline(always)]` and easily avoided by not using the attribute. if tcx.features().target_feature_11 && tcx.is_closure(did.to_def_id()) && codegen_fn_attrs.inline != InlineAttr::Always { </ins> let owner_id = tcx.parent(did.to_def_id()); if tcx.def_kind(owner_id).has_codegen_attrs() { codegen_fn_attrs

Discussion:
The preceding code used to compile successfully. Since the stabilization of in the compilation fails with:
Hm, I think related to and
Based on , I'm guessing it would be fine to allow with on closures, at least from a language perspective, even if it still trips up LLVM?
Technically, is "just a hint" and thus one solution is and always was to accept the inline annotation and then simply ignore the request.
But yes, I believe this code actually should be fully acceptable. Note that in that if is enabled, the attributes do get applied to the closure and inlining is done normally by LLVM due to a full match. No hint required.
Assigning P-low because the regression has been contained to nightly versions due to an immediate revert, so this only blocks forward feature development.
label: -regression-from-stable-to-nightly +requires-nightly
Change:
<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for functions --> $DIR/issue-118048.rs:7:6 | LL | foo!(_); |      ^ |      | |      not allowed in type signatures |      not allowed in type signatures | help: use type parameters instead | LL ~         fn foo<T>(_: $ty, _: $ty) {} LL |     } LL | } LL | LL ~ foo!(T); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0121`. </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
Probably just worth ignoring placeholder suggestions if they are coming from a different span ctxt than the fn -- either that, or logic to detect reuses of the same or something. Anyways, I think this is minimal: But I can't test it since I'm on my laptop.
Yeah can confirm this also triggers the debug assertion ^
Change:
<ins> // Checks that const expressions have a useful note explaining why they can't be evaluated. // The note should relate to the fact that it cannot be shown forall N that it maps 1-1 to a new // type. #![feature(const_generics)] #![allow(incomplete_features)] struct Collatz<const N: Option<usize>>; impl <const N: usize> Collatz<{Some(N)}> {} //~^ ERROR the const parameter struct Foo; impl<const N: usize> Foo {} //~^ ERROR the const parameter fn main() {} </ins>

Discussion:
The following code does NOT compile: it errors with: However, when using normal generics in the places of the const generics, wrapping the in an and sticking that into the struct does work: Is it intended that const generic dont mimmic this behaviour?
This is probably a decision that has to be made (although if it is disallowed, then we'd want a better error message). However, at present, this is a implementation limitation: we really only properly support const generics of the form at the moment (cc ).
Considering that anon consts are mostly just projections, wouldn't this be similar to which doesn't really make a lot of sense (we have to guarantee that the projection maps each value of to a unique type). While is injective, finding an intuitive subset of expressions for which this is the case is hard and imo not actually desirable rn. Not quite sure what's the best error message though :thinking: probably something like
That's a good point I think adding a note explaining the problem would be the best solution, though the tricky part is working out how to explain it concisely (rather than just stating what the problem is).
Change:
fn main() { (&ptr::write)(1 as *mut _, 42); //~^ ERROR E0133 <del> //~| NOTE unsafe call requires unsafe function or block </del> <ins> //~| NOTE call to unsafe function </ins> }

Discussion:
Label message always mention "unsafe call", even when nothing is actually called. It should duplicate the main message instead, or use some paraphrase of it. cc
How about this :
I've made a , please check the error messages again :)
Fix in , should be closed.
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_punctuation(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_punctuation() </del> <ins> match *self { '!'..='/' | ':'..='@' | '['..='`' | '{'..='~' => true, _ => false, } </ins> } /// Checks if the value is an ASCII graphic character:

Discussion:
I noticed this check: and wondered why it's there. Then someone told me it's there because of the . If you pass a non-ASCII char, the would corrupt that char. That's why the check is there before it. But then I wondered: why isn't this just cast to a bigger data type that includes all Unicode code points? This method (and others) are slower than they have to be. Also see this discussion in Discord with more valuable information:
(I can’t seem to find the relevant part in the middle of this discord stream…) I’m not sure what you mean by “corrupt”. is well defined: it takes the numerical value of the code point (same as ), then truncates to keep the lower 8 bits. equals 0x41, but so does . We want to reject the latter since U+1F041 is not an ASCII upper-case letter. If is implemented in terms of , the ASCII range check is necessary. (It could be a range check to, for example with .) But maybe doesn’t need to be implemented in terms of . Maybe it could duplicate the logic instead. Once upon a time was implemented with a lookup table of 256 entries. A flat lookup table for all of Unicode would be way too big. But these days it’s based on matching a range pattern. Doing the same with a range pattern could also work. That said, would it actually be faster? Maybe the optimizer already does its job well. If you want to work on this, consider adding some benchmark to show that code duplication is worth it.
Oh it seems the Discord link is a bit buggy. Try searching for in the search bar on the Discord server. Then you should get to my message with the discussion below it. One guy also posted this comparison of the instructions generated:
I think the minimal standard here should be a benchmark before we change the implementation. Can you provide that?
I'm not that experienced with Rust yet, sorry. I just wanted to point out this possible performance regression. Shouldn't the instruction amount difference as shown on Godbolt suffice to know that it's slower? vs.
Looking at the assembly, it seems that the problem is the check. These three functions produce : So, it seems that the check is unnecessary. I could make a PR for this.

Here are some benchmarks: So it seems that removing the check has a measurable performance difference.
is incorrect. The conversion should happen not for the ASCII check but for the , and the pattern use byte literals like . (Though I expect this won’t affect results much.)
Change:
<del> error: failed to find or create the directory specified by `--temps-dir` error: aborting due to previous error </del>

Discussion:
The test fails for me locally on the master branch (and was failing for a while now). I can of course ignore it, but it's annoying. also fails if run after/with . It looks like successfully creates a temp directory even if it's parent does not exist: <details<summaryoutput</summary<p</p</detailsThis causes the failure (as the test is expected to not compile) and also creates the directory, which then observes and also fails. This happens for me on the . cc iirc you had the same problems cc you changed those tests at some point, so maybe you know something
Summing up findings from discord, This test is wrong in its entirity since it gambles on permissions. The underlying subcommand creates the dir if you have enough permission to create in so it would fail. Otherwise, the directory is never created due to insufficient user permission, so the test passes. To sum it up, the test passed (for me) since I did not have enough permission to create a new directory () in : !
The test assumes that the compiler uses and so it must fail to create , but this is actually not the case: The test happens to pass in the CI and for many developers because you generally can't create a directory in . However this is not always the case (for example I happen to run tests in chroot). suggests that the proper fix for the test would be for the test to create an inaccessible directory, basically making a analog to
That still doesn't work if you're the root user, but I guess that's not what you're doing in your chroot? You could use a path like where even root can't create anything, but there's no OS-agnostic path like that.
I guess my point is that was broken on root anyway (because root has access to , same as in chroot). The explanation in the test was because of the original test it looks like, which works because it uses which requires at least the "parent must exist". So change -- now works on root, but doesn't work on chroot anymore does not work on root/chroot, but also doesn't clobber My change: unchanged now works in chroot Sooo, while fails on root, since it doesn't have global effects (clobbering as it originally did), I don't think it's a big deal.

IMO you are not supposed to run tests on root (but it's also bad for tests to have global effects)...
Yeah, that's fair -- we don't have to support root, but it should at least do no harm. While you're poking at that, maybe you can fix the filename spelling to "inaccessible"?
Fixed the spelling, thanks.
Change:
debug!("DST {} layout: {:?}", t, layout); let i = layout.fields.count() - 1; <del> let sized_size = layout.fields.offset(i).bytes(); </del> <ins> let unsized_offset_unadjusted = layout.fields.offset(i).bytes(); </ins> let sized_align = layout.align.abi.bytes(); <del> debug!("DST {} statically sized prefix size: {} align: {}", t, sized_size, sized_align); let sized_size = bx.const_usize(sized_size); </del> <ins> debug!( "DST {} offset of dyn field: {}, statically sized align: {}", t, unsized_offset_unadjusted, sized_align ); let unsized_offset_unadjusted = bx.const_usize(unsized_offset_unadjusted); </ins> let sized_align = bx.const_usize(sized_align); // Recurse to get the size of the dynamically sized field (must be

Discussion:
Execute with Miri: The problem is that and do not take the reduced field alignment into account and calculate the offset as-if the standard alignment was in place.
The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.
label I-prioritize (Looks like can't set .)
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'const-eval' ' "I-unsoun'... Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .
label -I-prioritize +P-medium
labels -T-types Discussed in types team on-site -- we think this is a MIR building bug, in any case, not part of T-types. Throwing hot back to compiler team.
It was actually a bug in the codegen backend, introduced when support for was -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.
Ah, scratch that -- there was a different related bug (the sizeofval / alignofval computation for packed structs with tail was wrong), caused by what I said above. This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong. This got fixed by ; will add a test.
Change:
<ins> error[E0275]: overflow evaluating the requirement `S<{ U }> well-formed` --> $DIR/adt_wf_hang.rs:11:5 | LL |     S<{ U }>:; |     ^^^^^^^^ | note: required by a bound in `S` --> $DIR/adt_wf_hang.rs:11:5 | LL | struct S<const N: U>() |        - required by a bound in this struct LL | where LL |     S<{ U }>:; |     ^^^^^^^^ required by this bound in `S` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0275`. </ins>

Discussion:
The compiler hangs on: searched nightlies: from nightly-2022-06-16 to nightly-2022-10-28 regressed nightly: nightly-2022-06-30 searched commit range: regressed commit: () label +A-const-generics +F-genericconstexprs +I-hang +T-compiler