jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass use std::ops::Deref; trait Foo { fn foo() -> impl Deref<Target = impl Deref<Target = impl Sized>> { &&() } } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: compiles, or a helpful error message Instead, this happened: Confusing error message, there doesn't seem to be a future that could be awaited?... Interestingly if the default implementation is removed, it compiles. 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
The error message on the playground is a bit different, seems to be correlating with the actual problem more, but even more confusing: Expected and found are the same!
Minimal: Something funky going on with the default projection predicate installed for the GAT. I'll look into it
I'm impressed by the speedy handling of this issue! Was hoping this would get a fix in a few weeks . You're awesome!
Once the pr is merged, it will be available the next day on nightly, correct? Btw, the pr failed some tests.
Change:
profiler_runtime, ptr_guaranteed_eq, ptr_guaranteed_ne, <ins> ptr_null, ptr_null_mut, </ins> ptr_offset_from, pub_macro_rules, pub_restricted,

Discussion:
I propose we add a lint that detects code like Some people seem to think that this is okay in contexts like or , but that is not the case -- on a NULL pointer is UB even as a place expression. To implement this, you can use the lint as a template: should check for  expressions with a operator, and then check the operand to be either a cast of to a pointer type, or a call to one of the methods. To detect the methods, make them "diagnostic items"; the lint does that e.g. for so it can again serve as a template here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ah, turns out clippy already has a lint for this: . So maybe we should just move that to rustc? Cc
claim
awesome. :) Let me know if you need any help.
Thanks :)
Did you mean something slightly different with your "okay in contexts like" examples, perhaps? Neither of those two actually compile as written, since they're just attempts to deference something that isn't even a pointer. You get: in both cases.
oops I screwed up the casts, should be fixed now.
Yeah, happy to have Clippy lints upstreamed to rust, let us know when it's done so we can deprecate it on our end
for detecting a call like you said to use . However I do not know what to use for the symbol argument. There is that defines symbol but nothing looks like creating a null ptr. Should I add one what should it look like ?
You first need to add the diagnostic item attribute to the relevant function inside , like so: This name must be globally unique, e.g. and . Then you add those names to the list in (please keep it alphabetically sorted), and then you can use them for .
Change:
Ok(Some(if self.token.is_keyword(kw::Let) { self.parse_local_mk(lo, attrs, capture_semi, force_collect)? <del> } else if self.is_kw_followed_by_ident(kw::Mut) { self.recover_stmt_local(lo, attrs, InvalidVariableDeclarationSub::MissingLet)? } else if self.is_kw_followed_by_ident(kw::Auto) { </del> <ins> } else if self.is_kw_followed_by_ident(kw::Mut) && self.may_recover() { self.recover_stmt_local_after_let(lo, attrs, InvalidVariableDeclarationSub::MissingLet)? } else if self.is_kw_followed_by_ident(kw::Auto) && self.may_recover() { </ins> self.bump(); // `auto` <del> self.recover_stmt_local(lo, attrs, InvalidVariableDeclarationSub::UseLetNotAuto)? } else if self.is_kw_followed_by_ident(sym::var) { </del> <ins> self.recover_stmt_local_after_let( lo, attrs, InvalidVariableDeclarationSub::UseLetNotAuto, )? } else if self.is_kw_followed_by_ident(sym::var) && self.may_recover() { </ins> self.bump(); // `var` <del> self.recover_stmt_local(lo, attrs, InvalidVariableDeclarationSub::UseLetNotVar)? </del> <ins> self.recover_stmt_local_after_let( lo, attrs, InvalidVariableDeclarationSub::UseLetNotVar, )? </ins> } else if self.check_path() && !self.token.is_qpath_start() && !self.is_path_start_item() { // We have avoided contextual keywords like `union`, items with `crate` visibility, // or `auto trait` items. We aim to parse an arbitrary path `a::b` but not something

Discussion:
<!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details label A-parser A-macros <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
cc this should probably be gated with your "may eagerly recover" work as well
This code is actually already mentioned in ;)
claim
Yeah, gating this recovery behind a is the correct fix here.
Also very fun that these things can ICE sometimes.
Found these also panic: Since these are highly related to the case, one pull request can fix all of these (maybe).
Change:
} } <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] impl Drop for LocalWaker { #[inline] fn drop(&mut self) { // SAFETY: This is safe because `LocalWaker::from_raw` is the only way // to initialize `drop` and `data` requiring the user to acknowledge // that the contract of `RawWaker` is upheld. unsafe { (self.waker.vtable.drop)(self.waker.data) } } } #[unstable(feature = "local_waker", issue = "118959")] </ins> impl fmt::Debug for LocalWaker { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let vtable_ptr = self.waker.vtable as *const RawWakerVTable;

Discussion:
The following code leaks memory: Miri error: The equivalent code with , so I think this is a bug. Cc
I guess this is not too surprising... has but has nothing like that.
Oh, that's may bad. I assumed that RawWaker handled ownership. I can push a PR today in the evening.
This leads to a miri-test-libstd failure every day, would be nice to get a fix soon. :)
Change:
[[package]] name = "serde" <del> version = "1.0.115" </del> <ins> version = "1.0.118" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "e54c9a88f2da7238af84b5101443f0c0d0a3bbdc455e34a5c9497b1903ed55d5" </del> <ins> checksum = "06c64263859d87aa2eb554587e2d23183398d617427327cf2b3d0ed8c69e4800" </ins> dependencies = [ "serde_derive", ] [[package]] name = "serde_derive" <del> version = "1.0.115" </del> <ins> version = "1.0.118" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "609feed1d0a73cc36a0182a840a9b37b4a82f0b1150369f0536a9e3f2a31dc48" </del> <ins> checksum = "c84d3526699cd55261af4b941e4e725444df67aa4f9e6a3564f18030d12672df" </ins> dependencies = [ "proc-macro2", "quote",

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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .
Change:
/// /// Consume any number less than 10. /// ``` <del> /// #![feature(peekable_next_if)] </del> /// let mut iter = (1..20).peekable(); /// // Consume all numbers less than 10 /// while iter.next_if(|&x| x < 10).is_some() {} /// // The next value returned will be 10 /// assert_eq!(iter.next(), Some(10)); /// ``` <del> #[unstable(feature = "peekable_next_if", issue = "72480")] </del> <ins> #[stable(feature = "peekable_next_if", since = "1.51.0")] </ins> pub fn next_if(&mut self, func: impl FnOnce(&I::Item) -> bool) -> Option<I::Item> { match self.next() { Some(matched) if func(&matched) => Some(matched),

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for the feature (). The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the RFC [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should be named or ? Should be named or ?
modify labels: T-libs
I don't think the methods should be renamed to something else, becuase also has a method, and should use the same name but with the component. Also, if these questions are resolved and there are no other blockers, I would like to go ahead and stabilize this feature.
Change:
use crate::sys::c; use crate::sys::cvt; use crate::sys::handle::Handle; <ins> use core::str::utf8_char_width; </ins> // Don't cache handles but get them fresh for every read/write. This allows us to track changes to // the value over time (such as if a process calls `SetStdHandle` while it's running). See #40490. pub struct Stdin { surrogate: u16, } <del> pub struct Stdout; pub struct Stderr; </del> <ins> pub struct Stdout { incomplete_utf8: IncompleteUtf8, } pub struct Stderr { incomplete_utf8: IncompleteUtf8, } struct IncompleteUtf8 { bytes: [u8; 4], len: u8, } </ins> // Apparently Windows doesn't handle large reads on stdin or writes to stdout/stderr well (see // #13304 for details).

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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<summaryBacktrace</summary<p</p</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.
Change:
pub prints: Vec<PrintRequest>, pub cg: CodegenOptions, pub color: ColorConfig, <del> pub show_span: Option<String>, </del> pub externs: HashMap<String, Vec<String>>, pub crate_name: Option<String>, /// An optional name to use as the crate for std during std injection,

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be
Change:
<ins> LL|       |// edition: 2021 LL|       | LL|       |// If the span extractor can't find any relevant spans for a function, LL|       |// but the function contains coverage span-marker statements (e.g. inserted LL|       |// for `if !`), coverage codegen may think that it is instrumented and LL|       |// consequently complain that it has no spans. LL|       |// LL|       |// Regression test for <https://github.com/rust-lang/rust/issues/118850>, LL|       |// "A used function should have had coverage mapping data but did not". LL|       | LL|      1|fn main() { LL|      1|    affected_function(); LL|      1|} LL|       | LL|       |macro_rules! macro_that_defines_a_function { LL|       |    (fn $name:ident () $body:tt) => { LL|       |        fn $name () $body LL|       |    } LL|       |} LL|       | LL|       |macro_that_defines_a_function! { LL|       |    fn affected_function() { LL|       |        if !false { LL|       |            () LL|       |        } else { LL|       |            () LL|       |        } LL|       |    } LL|       |} </ins>

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
tcx: TyCtxt<'tcx>, key: ty::ParamEnvAnd<'tcx, GlobalId<'tcx>>, ) -> ::rustc_middle::mir::interpret::EvalToConstValueResult<'tcx> { <del> // see comment in const_eval_raw_provider for what we're doing here </del> <ins> // see comment in eval_to_allocation_raw_provider for what we're doing here </ins> if key.param_env.reveal() == Reveal::All { let mut key = key; key.param_env = key.param_env.with_user_facing();

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

<!-- 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</detailsI think I'm an ICE magnet; this is my fourth one.
I'd like to note that it only ICEs with the wrong return type. The following does not ICE
Change:
<ins> #![feature(generators)] // edition:2018 // Regression test for #67158. fn main() { async { yield print!(":C") }; //~ ERROR `async` generators are not yet supported } </ins>

Discussion:
This code () produces ICE on current beta and nightly
Tagging as P-medium and "triaged" for async-await. Note that yield is unstable.
the feature is nightly but the ice doesn't require any feature gate to trigger.
searched nightlies: from nightly-2019-01-01 to nightly-2020-02-01 regressed nightly: nightly-2019-09-29 searched commits: from to regressed commit: source code: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
thanks for the bisection! Annoyingly, it regressed in a rollup PR, which means there are many candidates: (Docs: slice elements are equidistant) -- (Include message on tests that should panic but do not) -- (Remove stray references to the old global tcx) -- (Remove unused DepTrackingMap) -- (Account for tail expressions when pointing at return type) -- (hir: Disallow on constants) -- (Fix divduration() marked as stable by mistake) -- (update rtpSpawn's parameters type(It's prototype has been updated in libc)) -- (Thou shallt not ) -- (Stabilize mapgetkeyvalue feature) -- ( fix links to primitives in documentation) -- (Upgrade envlogger to 0.7) -- (Add mailmap entry for Dustin Bensing by request) -- (check_match: improve diagnostics for with ) --
If I had to guess, I would guess (cc triggered this regression, but or are possibilities. I would guess because it caused the compiler to keep compiling when it might've aborted, and maybe it would've aborted in these cases and hence never reached the code that causes an ICE. If indeed I am correct, then this could be fixed by adding a call at the point of the ICE (i.e., basically asserting that some error has occurred but otherwise just try to not crash).
Change:
// Align the maximum variant size to the largest alignment. size = size.align_to(align.abi); <ins> // FIXME(oli-obk): deduplicate and harden these checks </ins> if size.bytes() >= dl.obj_size_bound() { return None; }

Discussion:
rustc generally detects when a static type is larger than bytes, giving an error that + 10x80000000isize::MAX + 1`): (The is to ensure that an object of size is actually created on the stack.) This is clearly unsound, since it breaks the size invariant of , and since third-party crates may depend on types being no larger than for soundness. However, it's nontrivial to observe unexpected behavior from this using only safe APIs in the standard library, since placing the overlarge type within any other type, even a wrapper, will result in a compile error as expected, and the standard APIs tend to refer to when creating a slice from a reference.
Wow, good catch! Looks like we're doing the check before rounding up to the next multiple of alignment? That's bad.
Change:
//! [`OsStr`] and Rust strings work similarly to those for [`CString`] //! and [`CStr`]. //! <del> //! * [`OsString`] represents an owned string in whatever //! representation the operating system prefers. In the Rust standard //! library, various APIs that transfer strings to/from the operating </del> <ins> //! * [`OsString`] losslessly represents an owned platform string. However, this //! representation is not necessarily in a form native to the platform. //! In the Rust standard library, various APIs that transfer strings to/from the operating </ins> //! system use [`OsString`] instead of plain strings. For example, //! [`env::var_os()`] is used to query environment variables; it //! returns an <code>[Option]<[OsString]></code>. If the environment variable

Discussion:
The [documentation for ] says— The [documentation for § "Representations of non-Rust strings"] says— These statements led me to understand that— on Microsoft Windows, an would represent its text as "arbitrary sequences of non-zero 16-bit values", and not as UTF-8, and thus on Windows, an would reference such a non-UTF-8 sequence, and thus [] — which returns an al that (by my imperfect understanding of Rust reference rules) would have to reference the same thing as the — almost always would return on Windows (except for, e.g., empty strings), because a Windows string could not validly be read as a Rust . However, tells me that— "OsStr::tostr on Windows will succeed most of the time", stores its text in WTF-8 on Windows, and it's more accurate [than what the documentation says] to say that OsStr represents an owned string in a representation capable of handling any string received from the operating system Was my misinterpretation of the documentation unreasonable? If not, could the documentation be clarified on this point? [documentation for ]: [documentation for § "Representations of non-Rust strings"]: []:
Agreed on pretty much all points here. In addition, it would be really useful to have some guidance on the best way to convert an OsStr(ing) to an LPWSTR so that it can be actually used with windows apis. Either here or in winapi-rs, not sure where the best fit would be.
I would like to be able to losslessly transcode between a [] and an []. A [] may contain zeros, however. []: []:
may also contain zeros.