jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0310]: the parameter type `T` may not live long enough --> $DIR/issue-98693.rs:15:5 | LL | /     || { LL | | LL | |         assert_static::<T>(); LL | |     }; | |_____^ ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound... | LL | fn test<T: 'static>() { |          +++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
only be referred to via one of the pointer types. Other pointer types work as well. Casts to traits may only be done with compatible pointers so, <del> for example, an `@Circle` may not be cast to an `~Drawable`. </del> <ins> for example, an `&Circle` may not be cast to an `~Drawable`. </ins> ~~~ # type Circle = int; type Rectangle = int;

Discussion:
Their continued existence in the tutorial is causing confusion over what the status of this feature is. Let all the world know that managed pointers are relegated to the dustbin of history!
It's unclear to me if the tutorial is being rewritten from scratch by Mozilla. There's not much motivation for anyone to work on it if it's just going to be thrown out.
That may be true, but if a good samaritan wanted to do just enough work to delete mentions of them from the current tutorial, it would not be unappreciated.
Hi, I am the one who asked about this initially. I have started to work on it now.
At this point I do think it's worthwhile to keep maintaining the tutorial. Even if it doesn't survive as the tutorial, it does contain a lot of information that will end up disseminated elsewhere.
Not maintaining the tutorial leads to a growing collection of inaccurate or wrong information. Removing it could give newcomers a better first-time experience of Rust.
Change:
///     assert_eq!(rebuilt, [4, 5, 6]); /// } /// ``` <ins> /// /// Using memory that was allocated elsewhere: /// /// ```rust /// #![feature(allocator_api)] /// /// use std::alloc::{AllocError, Allocator, Global, Layout}; /// /// fn main() { ///     let layout = Layout::array::<u32>(16).expect("overflow cannot happen"); /// ///     let vec = unsafe { ///         let mem = match Global.allocate(layout) { ///             Ok(mem) => mem.cast::<u32>().as_ptr(), ///             Err(AllocError) => return, ///         }; /// ///         mem.write(1_000_000); /// ///         Vec::from_raw_parts_in(mem, 1, 16, Global) ///     }; /// ///     assert_eq!(vec, &[1_000_000]); ///     assert_eq!(vec.capacity(), 16); /// } /// ``` </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub unsafe fn from_raw_parts(ptr: *mut T, length: usize, capacity: usize) -> Self {

Discussion:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.
Change:
}; self.tcx.emit_spanned_lint( lint, <del> hir_id, </del> <ins> self.tcx.hir().local_def_id_to_hir_id(self.item_def_id), </ins> span, PrivateInterfacesOrBoundsLint { item_span: span,

Discussion:
I tried this code: I expected to see this happen: The lint is allowed. Instead, this happened: The lint still triggers. (Applying to the entire module works). (I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it). Latest playground nightly:
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
cc
Change:
bad: data[4..=2]; message: "but ends at"; } <ins> in mod boundpair_neg_width { data: [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(4), Bound::Excluded(4))] == []; bad: data[(Bound::Included(4), Bound::Excluded(3))]; message: "but ends at"; } </ins> } panic_cases! {

Discussion:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)
Change:
<ins> error[E0726]: implicit elided lifetime not allowed here --> $DIR/bad-region.rs:12:6 | LL | impl BleRadio for Radio { |      ^^^^^^^^ expected lifetime parameter | help: indicate the anonymous lifetime | LL | impl BleRadio<'_> for Radio { |              ++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0726`. </ins>

Discussion:
I was developing one trait in one crate, changing it to use a lifetime, and forgot to add it to the other crate's implementation. The compiler shows de correct error message but breaks. If I fix the code, adding the lifetime to the trait, de compiler works. If it is in the same crate also works. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Same backtrace as .
Thanks for the minimized test! I'll fix this tomorrow.

<!-- 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. --While I was trying to add lifetimes for picoserve's I got into ICE (1.) had a dep of picoserve as 2. That code isn't finished and should not compile yet <!-- 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. --: has ice files
rustc 1.75.0 ( 2023-12-21) binary: rustc commit-hash: commit-date: 2023-12-21 host: x86_64-unknown-linux-gnu release: 1.75.0 LLVM version: 17.0.6 Here ICE is also present
Backtrace from one of the linked files pasted below for the sake of searchability and preservation: <details<summaryBacktrace</summary</details
Change:
<ins> error: pointers cannot be reliably compared during const eval --> $DIR/different-fn-ptr-binders-during-ctfe.rs:2:5 | LL |     x == y |     ^^^^^^ | = note: see issue #53020 <https://github.com/rust-lang/rust/issues/53020> for more information error: aborting due to 1 previous error </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'', 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'' 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: [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
Regression in cc
that seems off :sweat_smile: this PR should not result in behavior differences
ah yes my bad :D I left in by accident from a previous bisection and that was the pr that the flag :laughing:
should exist since pretty much forever :grin: 1.48
Regression in nightly-2023-04-20 fetching (via remote github) commits from max(, 2023-04-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 10 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests,

r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3
This might be related to cc one nightly before this errors with so maybe const-related
the cause is that the assert mentioned in is wrong. COmparing pointers with different bound vars is ok. This should either use actual semantic equality or just yeet the assert
Change:
assert_eq!(kind, "lifetime"); let provided = force_infer_lt.expect("lifetimes ought to have been inferred"); <del> Self::generic_arg_mismatch_err(tcx.sess, provided, kind); </del> <ins> Self::generic_arg_mismatch_err(tcx.sess, provided, kind, None); </ins> } break;

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim
Change:
<ins> struct Foo(u32, u32); impl Foo { fn foo(&self) { match *self { Foo::(1, 2) => {}, //~ HELP: consider removing the `::` here to turn this into a tuple struct pattern //~^ NOTE: while parsing this parenthesized list of type arguments starting //~^^ ERROR: expected type, found `1` //~^^^ NOTE: expected type _ => {}, } } } fn main() {} </ins>

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
/// Uniquely identifies one of the following: /// - A constant /// - A static <del> /// - A const fn where all arguments (if any) are zero-sized types </del> #[derive(Copy, Clone, Debug, Eq, PartialEq, Hash, TyEncodable, TyDecodable)] #[derive(HashStable, Lift)] pub struct GlobalId<'tcx> {

Discussion:
Since , memoization of argumentless functions is restricted to intrinsics, because other functions could perform heap allocations and thus memoization would be incorrect. I doubt we have any argumentless intrinsic that is expensive enough that memoization is worth it, so I propose we remove the leftovers of that infrastructure. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I want to work on this but i never contributed to rust-lang before so i need some guidance.
Great! So... step 0 is to write as a comment here, this will make sure the issue is assigned to you and noone else tries to tackle it at the same time. The main change is to remove this function: entirely without a replacement. You'll then have to adjust the call site to act as if the function returned . This may allow some small cleanups at the call site; I expect nothing major to happen there. I do not think there will be further test changes due to this, so, should run through without any failures. If it doesn't, still open a PR and let us know of your findings.
claim
Change:
// the merge has confused the heck out of josh in the past. // We pass `--no-verify` to avoid running git hooks like `./miri fmt` that could in turn // trigger auto-actions. <del> sh.write_file("rust-version", &commit)?; </del> <ins> sh.write_file("rust-version", format!("{commit}n"))?; </ins> const PREPARING_COMMIT_MESSAGE: &str = "Preparing for merge from rustc"; cmd!(sh, "git commit rust-version --no-verify -m {PREPARING_COMMIT_MESSAGE}") .run()

Discussion:
You can't create pure closures right now. This is sometimes helpful in writing functions that operate on const data. I think this will just be a matter of adjusting typeck to determine purity from the expected type.

As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .
Change:
<ins> error[E0308]: `match` arms have incompatible types --> $DIR/issue-81839.rs:11:14 | LL | /     match num { LL | |         1 => { LL | |             cx.answer_str("hi"); | |             -------------------- | |             |                  | | |             |                  help: consider removing this semicolon | |             this is found to be of type `()` LL | |         } LL | |         _ => cx.answer_str("hi"), | |              ^^^^^^^^^^^^^^^^^^^ expected `()`, found opaque type LL | |     } | |_____- `match` arms have incompatible types | ::: $DIR/auxiliary/issue-81839.rs:6:49 | LL |       pub async fn answer_str(&self, _s: &str) -> Test { |                                                   ---- the `Output` of this `async fn`'s found opaque type | = note:     expected type `()` found opaque type `impl Future` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim
Change:
= help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[BarB]` cannot be resolved, ignoring it... <del> --> $DIR/intra-links-warning.rs:28:1 </del> <ins> --> $DIR/intra-links-warning.rs:30:9 </ins> | <del> LL | / /** LL | |  * Foo LL | |  * bar [BarB] bar LL | |  * baz LL | |  */ | |___^ </del> <ins> LL |  * bar [BarB] bar |         ^^^^ cannot be resolved, ignoring </ins> | <del> = note: the link appears in this line: bar [BarB] bar ^^^^ </del> = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[BarC]` cannot be resolved, ignoring it... <del> --> $DIR/intra-links-warning.rs:35:1 </del> <ins> --> $DIR/intra-links-warning.rs:37:6 </ins> | <del> LL | / /** Foo LL | | LL | | bar [BarC] bar LL | | baz ...  | LL | | LL | | */ | |__^ </del> <ins> LL | bar [BarC] bar |      ^^^^ cannot be resolved, ignoring </ins> | <del> = note: the link appears in this line: bar [BarC] bar ^^^^ </del> = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[BarD]` cannot be resolved, ignoring it...

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs: