jiebi/CodeConvo huggingface dataset:
Code change:
<del> // check-pass // From https://github.com/rust-lang/rust/issues/72476 trait A { type Projection; } impl A for () { type Projection = bool; } struct Next<T: A>(T::Projection); fn f(item: Next<()>) { match item { Next(true) => {} Next(false) => {} } } fn main() {} </del>

Related discussion:
text: <!-- 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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.
Code change:
| help: change the delimiters to curly braces | <del> LL | y!{ LL | Ϥ} | </del> <ins> LL | y! { /* items */ } |    ^^^^^^^^^^^^^^^ </ins> help: add a semicolon | LL | Ϥ,;

Related discussion:
text: I'm seeing an internal compiler error on the following input (found by ): My compiler version is: I also observe the error on , but not on .
Code change:
error!("This is an error log") warn!("This is a warn log") info!("this is an info log") <del> debug!("This is a dubug log") </del> <ins> debug!("This is a debug log") </ins> } ```

Related discussion:
text: The logging section of the 0.6 docs ( ) doesn't specify how you log messages. This link is broken: It is not broken in the 0.5 docs, but I believe the API has changed.
Code change:
// rustc internal (active, staged_api, "1.0.0", None), <del> // Allows using items which are missing stability attributes // rustc internal (active, unmarked_api, "1.0.0", None), </del> // Allows using #![no_core] (active, no_core, "1.3.0", Some(29639)),

Related discussion:
text: According to and in , this feature-gate should not be used. It appears that earlier error checking in the compiler prevents it from ever mattering anyway.
Code change:
AssocTypeItem(t, b) => ItemEnum::AssocType { generics: t.generics.into_tcx(tcx), bounds: b.into_iter().map(|x| x.into_tcx(tcx)).collect(), <del> default: t.item_type.map(|ty| ty.into_tcx(tcx)), </del> <ins> default: Some(t.item_type.unwrap_or(t.type_).into_tcx(tcx)), </ins> }, // `convert_item` early returns `None` for striped items and keywords. StrippedItem(_) | KeywordItem(_) => unreachable!(),

Related discussion:
text: Run with this in : and inspect . There is an item for the of the blanket impl  and it's default value is . There is an item but the default value is missing. It looks like this: When using instead of the information about the default value is present. It looks like this: This change, which in practice is a regression, is caused by But we can't revert it of course because that will result in ICEs which is even worse. So we need some kind of follow-up fix. labels +A-rustdoc-json +T-rustdoc +C-bug +requires-nightly
It seems like you already suggested a fix. Want to open a PR for it?
Yep I will do that as soon as I get time. Probably today.
It's not in a hurry. Don't hesitate to ask if you need help.
Code change:
- [Rustc now catches more cases of `pub_use_of_private_extern_crate`][80763] - [Changes in how proc macros handle whitespace may lead to panics when used with older `proc-macro-hack` versions. A `cargo update` should be sufficient to fix this in all cases.][84136] <ins> - [Turn `#[derive]` into a regular macro attribute][79078] </ins> [84136]: https://github.com/rust-lang/rust/issues/84136 [80763]: https://github.com/rust-lang/rust/pull/80763

Related discussion:
text: <!-- 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. --Input to is able to see underlying derive attributes. This is not supposed to happen as per the change in . A to remove this effect. But onwards, underlying attributes are visible again to derive and this is not mentioned in . Example code is available here: In the following code below, generates a function named which prints all derive attributes visible to it. is defined as: Ouputs a blank line: : :
cc - I believe the new behavior is the one we want, since it makes derived 'just another attribute'. If so, we should document it more clearly in the release notes.
This change was made by , but that PR was never tagged with for some reason.
Triage: dropping and as this isn't an actual regression.
Code change:
<ins> // build-pass fn main() { let _ = &[(); usize::MAX]; } </ins>

Related discussion:
text: <!-- 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: code compiles in a reasonable amount of times or the slice gets elided entirely. Instead, this happened: code takes multiple minutes to compile/gets killed by the playground. <!-- 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. --: Also tested on playground stable and nightly.
The code compiled in about 6 seconds in Rust 1.29 and 1.30 : . Before that it had capacity error. After that it exceeded 15 seconds limit of godbolt. This is a but I cannot tag it.
It looks like this also works correctly on 1.31 stable as well:
Decided on as in the prioritization working group procedure.
Cc
Fixed in .
Code change:
}; if self.in_root && item.vis.node.is_pub() { <del> self.derives.push(ProcMacroDerive { </del> <ins> self.macros.push(ProcMacro::Derive(ProcMacroDerive { </ins> span: item.span, trait_name: trait_ident.name, function_name: item.ident, attrs: proc_attrs, <del> }); </del> <ins> })); </ins> } else { let msg = if !self.in_root { "functions tagged with `#[proc_macro_derive]` must 

Related discussion:
text: The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)
Code change:
use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt; use rustc_session::Session; <ins> use rustc_span::hygiene::DesugaringKind; </ins> use rustc_span::Span; #[derive(Clone, Copy, Debug, PartialEq)]

Related discussion:
text: I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim
Code change:
<ins> fn g() where 'static: 'static, dyn 'static: 'static + Copy, //~ ERROR at least one trait is required for an object type { } fn main() {} </ins>

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- 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
I think this is the code crashing: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than , , or
No longer crashing: `
Code change:
// except according to those terms. struct BuildData { <ins> foo: isize, //~ NOTE `foo` first declared here </ins> foo: isize, <del> foo: isize, //~ ERROR field `foo` is already declared </del> <ins> //~^ ERROR field `foo` is already declared [E0124] //~| NOTE field already declared </ins> } fn main() {

Related discussion:
text: From: src/test/compile- Error E0124 needs a spanlabel and a spannote replaced with a span_label, updating it from: To:
Error message updated in .
Code change:
let ans = s(); //~^ ERROR this function takes 1 parameter but 0 parameters were supplied //~| NOTE the following parameter type was expected <ins> //~| NOTE expected 1 parameter </ins> let ans = s("burma", "shave"); //~^ ERROR this function takes 1 parameter but 2 parameters were supplied //~| NOTE the following parameter type was expected <ins> //~| NOTE expected 1 parameter </ins> }

Related discussion:
text: From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.
Code change:
// FIXME we need to revisit this for #67176 if rvalue.has_param() { <ins> trace!("skipping, has param"); </ins> return None; } if !rvalue

Related discussion:
text: Fuzzer generated MIR, reduced, and UB-free under Miri (for real this time :sweatsmile:) Segfaults with enabled: , which is a valid pointer, somehow got propagated as 0: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That seems undesirable. Is there a surface Rust program that can produce this MIR? Asking primarily for prioritization purposes.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Minimized test case:
Here's an example using stable surface syntax (). Seems to have been introduced in 1.70, with in particular.
Nevermind seems like I was wrong. <details</details
It's not an LLVM miscompilation, the code is already by the time it goes to LLVM. With So it's defiantly happening in MIR ConstProp
The problem seems to be that when running on the statement , the frames arn't updated, so when it runs on , it thinks is their for local . , on to add logging and test. ()
claim
Cc
Code change:
relevant_pr_url, relevant_pr_user, pr_reviewer, <del> current_datetime </del> <ins> current_datetime, github_token, </ins> ): <ins> # type: (str, str, str, str, str, str, str) -> str </ins> '''Updates `_data/latest.json` to match build result of the given commit. ''' with open('_data/latest.json', 'r+') as f:

Related discussion:
text: Updated the toolstate repository at https://rust-lang- currently does not seem to work, see e.g. To "tool failed to build"-issues are being created, either. remarked that the error . Cc
Code change:
impl<T: fmt::Debug> ops::FnOnce<(),> for Debuger<T> { type Output = (); fn call_once(self, _args: ()) { <del> //~^ ERROR `call_once` has an incompatible type for trait: expected "rust-call" fn, found "Rust" fn </del> <ins> //~^ ERROR `call_once` has an incompatible type for trait //~| expected "rust-call" fn, //~| found "Rust" fn </ins> println!("{:?}", self.x); } }

Related discussion:
text: The multi-line errors should be extended to include this testcase. missed this because the didn't go through . I tried but that didn't work either. If someone can point me to to where to catch it, I can probably fix this too. cc Code: Error: Change to:
Code change:
error[E0038]: the trait alias `SelfInput` cannot be made into an object <del> --> $DIR/self-in-generics.rs:5:19 </del> <ins> --> $DIR/self-in-generics.rs:12:19 </ins> | LL | pub fn f(_f: &dyn SelfInput) {} |                   ^^^^^^^^^

Related discussion:
text: <!-- 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
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:
Code change:
use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

Related discussion:
text: In , it was uncovered that is making some rather strong assumptions: two s with different address but the same type must not overlap. Not only is this a scarily non-local safety invariant, it is also fundamentally incomaptible with some APIs that ought to be correct, as demonstrated by this snippet (thanks to and for help with working out the example): to see the issue: will duplicate parts of the memory range when there is overlap, which leads to double-drop (other parts of the memory range are just lost, leading to memory leaks, but that is not the main issue here). This is not itself a soundness issue as it requires unsafe code to trigger UB. But this likely reflects an unintended consequence of . This got stabilized in as part of That commit references and an RFC, but is not mentioned in either of them. was in Accept that is unsound and document "non-overlap" as part of the safety invariant. This seems very fragile. Make not misbehave on overlap, either by panicking or by only swapping the non-overlapping parts. Cc
was in , which was authored by a "Charlie Fan". This is probably
Cc
This makes the method sound, but it seems like there could be other seems-like-they-should-be-ok cell projections that break under this behavior.
I don't think so. This makes the function behave "strangely", but since no data is duplicated nor discarded, I think it is sound.
I share this hunch, although the code, out of nowhere, may look very contrived. Consider: So it seems like -king (at least for non- types) is the only option that would allow us too keep the structural property of s, which, imho, is a very intuitive programmer mindset (and thus, a mistake that many would do should they not know about this caveat), and so a quite important thing to preserve .
That is an example of the "strange" behavior not being the right thing for this code, but it is not an unsoundness of per se. Your unsafe code is simply making wrong assumptions about the functional behavior of . Current favors the first operand in case of overlap (according to documentation); unsafe code that incorrectly assumes it would favor the second operand would be equally wrong. I don't see a bug in either way. IMO it seems rather strange to only panic for non- types.
Code change:
use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

Related discussion:
text: Btw, also exists. does not have array/slice projection functions though and they would be wrong due to the counts, so overlapping probably truly are not a thing.
At the very least, an argument that aren't allowed to overlap is easier to defend than that aren't allowed to overlap. Plus also, doesn't have guaranteed layout in the first place, so any example using tuples is (currently) implementation-detail-tied even before hitting . You could still construct an example using only types, of course; just replace the tuple with an actual type. You could even make it . As I understand it, there's three main cases here. ping two nonoverlapping is fine. ping two partially overlapping without any bound on has a sound, if surprising, definition, where the nonoverlapping part of the arrays are swapped. ping two partially overlapping unknown is unsound in any definition, unless both has no safety invariants and the overlapping portion is . The third case is obviously the most restricting one, and is defined on . To expound on first of the two subissues: Consider a type with the extra safety invariant that the second must be double the first . could even be . It would be valid to create two from , as you'd have and . There is no possible definition of (other than a no-op) which preserves the safety invariant. And of course the impl doesn't even know about the safety invariant. I could probably create an even worse example using underaligned types and relying on a specific endianness, perhaps even accidentally breaking validity invariants (think around partially overlapping ). The only two resolutions I'm confident in are making always panic for overlapping cells (because there could be safety invariants being broken) or forbidding overlapping s to -compatible types (optionally: that would be broken by ). And I don't like the subtle implications of the latter (e.g. being unsound for unbound ).
I don't think would be immediately unsound, you would still need a way to create overlapping s.
In particular, they certainly can only overlap in restricted ways -- if they overlap such that one's sits on the other's , I can already cause UB without just by storing into that and then reading it as a . Oh I see... to only swap the non-overlapping parts we have to make an argument that these parts have the same type (safety+validity invariant).
Code change:
use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

Related discussion:
text: Which... seems utterly bogus now that I think about it. Worse, the invariant could correlate the overlapping with the non-overlapping part, as in your example. (Removed a whole bunch of nonsense where I try to find some special cases that work.) Yeah we should make it panic.^^ It is unsound to create an to these though, even without I can already violate the safety invariant here by setting the second reference to . Ergo this is not a problem for , we can already assume such references do not exist. I am confused, is there a negation missing somewhere in this sentence?
Fair. I'm fairly confident that it'd be possible to come up with some safety invariant that a partial swap would break, though, with more data-dependent qualities. The parenthetical is an optional relaxation of the potential requirement (but at the cost of a lot of complexity).
But shouldn't it be forbidding overlapping s to -incompatible types? Not that I know what either of these things mean, but forbidding incompatible seems to make more sense than forbidding compatible.^^
Yeah, poor verbage. I meant roughly "forbidding overlapping s of types that can be used in (i.e. sized types)", with the optional extension of "only for those actually broken by " (however that would be defined).
that partially overlapping s through an enum is problematic even without :
Enums isn't really the same thing. That enum projections are unsound , but as also discussed in that article, struct projections are typically ok, and the array projection discussed here is essentially a struct projection, not an enum projection.
I would like to bring up my crate  which allows projecting through using a macro. example usage: Note: doesn't allow projecting through enums for exactly the reasons that explained. I'm not sure how could interact with to produce bad behavior, because you can only project to fields, which can't be swapped with their parent, but just in case someone else finds something interesting. i.e. This isn't possible, so it's not possible to project through to a field that's the same type as the parent. Alongside the fact that all fields are disjoint means that cell-project should only produce overlapping if they are also .
I agree with here. Sum types and product types are different, and really should commute around product types, i.e., ought to be sound.
Code change:
use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

Related discussion:
text: You can use , which led me to this issue (it'd be good if we could support field projection inside of and ).
While you could use to check that the tuple layout conforms to the C-like layout needed to do such projection, I don't see how your specific use of would lead to two partially overlapping though. Note that the problem is not with projecting to a single field, but to a group/subset containing multiple fields (or like in the array/slice example, to a subarray/subslice with length ).
Oh I see, you're right. False alarm.
Code change:
<ins> error[E0038]: the trait alias `BB` cannot be made into an object --> $DIR/self-in-const-generics.rs:9:16 | LL | fn foo(x: &dyn BB) {} |                ^^ | = note: it cannot use `Self` as a type parameter in a supertrait or `where`-clause error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. </ins>

Related discussion:
text: <!-- 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
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following: