jiebi/CodeConvo huggingface dataset:
Change:
//! //! ## On Windows //! <ins> //! An [`OsStr`] can be losslessly converted to a native Windows string. And //! a native Windows string can be losslessly converted to an [`OsString`]. //! </ins> //! On Windows, [`OsStr`] implements the //! <code>std::os::windows::ffi::[OsStrExt][windows.OsStrExt]</code> trait, //! which provides an [`encode_wide`] method. This provides an <del> //! iterator that can be [`collect`]ed into a vector of [`u16`]. </del> <ins> //! iterator that can be [`collect`]ed into a vector of [`u16`]. After a nul //! characters is appended, this is the same as a native Windows string. </ins> //! //! Additionally, on Windows [`OsString`] implements the //! <code>std::os::windows:ffi::[OsStringExt][windows.OsStringExt]</code> <del> //! trait, which provides a [`from_wide`] method. The result of this //! method is an [`OsString`] which can be round-tripped to a Windows //! string losslessly. </del> <ins> //! trait, which provides a [`from_wide`] method to convert a native Windows //! string (without the terminating nul character) to an [`OsString`]. </ins> //! //! [Unicode scalar value]: https://www.unicode.org/glossary/#unicode_scalar_value //! [Unicode code point]: https://www.unicode.org/glossary/#code_point

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.
Change:
self.suggest_remove_reference(&obligation, &mut err, &trait_ref); self.suggest_semicolon_removal(&obligation, &mut err, span, &trait_ref); self.note_version_mismatch(&mut err, &trait_ref); <del> self.suggest_await_before_try(&mut err, &obligation, &trait_ref, span); </del> <ins> if Some(trait_ref.def_id()) == tcx.lang_items().try_trait() { self.suggest_await_before_try(&mut err, &obligation, &trait_ref, span); } </ins> if self.suggest_impl_trait(&mut err, span, &obligation, &trait_ref) { err.emit(); return;

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 rustc compiler panics for being unable to check the type of an object. In the example, it's shown in the form of returning an Option, and being unable to take Option as a parameter type. This would be the expected compilation error for that snippet of code, but instead of that, the compiler just panics. This error only occurs on asynchronous functions and in nightly. It also only happens when not compiling with --release, only in debug. <!-- 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</details
cc (likely due to - )
I can see why that could cause it. I've also seen that could be caused due to a similar issue. If it's the same issue, this issue should be kept as it provides a smaller example to reproduce and extra information in reproducing.
oh, sorry, my bad, investigating.
Kind of strange, this ice only triggered with , won't ice. here is a mcve: ICE: no-ICE:

<!-- 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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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 realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.
Change:
<ins> // run-rustfix #![allow(dead_code)] // https://github.com/rust-lang/rust/issues/112007 fn bug_report<W: std::fmt::Write>(w: &mut W) -> std::fmt::Result { if true { writeln!(w, "`;?` here ->")?; } else { writeln!(w, "but not here") //~^ ERROR mismatched types } Ok(()) } macro_rules! baz { ($w: expr) => { bar!($w) } } macro_rules! bar { ($w: expr) => { writeln!($w, "but not here") //~^ ERROR mismatched types } } fn foo<W: std::fmt::Write>(w: &mut W) -> std::fmt::Result { if true { writeln!(w, "`;?` here ->")?; } else { baz!(w) } Ok(()) } fn main() {} </ins>

Discussion:
The suggestion converts the code to: which is invalid. It should suggest: The suggestion works correctly for non-macro string values. This suggestion was introduced in . No response
It cannot be reproduced on .
I'm able to reproduce it locally. It seems to be suggesting a change in : (note the path) I assume that this is due to macro expansion. It might not be working on the playground because the playground doesn't have the component installed but that's a total guess.
The presence of only affects the human-readable rendering. The important part to me is the JSON output which has even without rust-src. Ideally it would be something closer to what it looks like with :
It seems to affect all macro expansions ():
Is the solution to just disable this suggestion for macro-expanded code? As an aside, perhaps the playground should get , especially because of its prevalence in sharing code which might need the additional context.
I think it's possible to achieve the desired output found in the description, although I'm not sure how exactly. Typically, you would use on the span to peel away the layers of macro invocations, though for that you would need to provide a parent to mark the end of the chain. doesn't need such a stopper but here its use would be incorrect if the macro call itself (e.g. ) was inside of a macro expansion. Since we don't have a parent (afaiaa), earlier I briefly tried to create a parent for via I think but that didn't work. Maybe could work, not sure. This approach is a catch-22 I believe.
Yeah, would that be the desired solution though? Can this be generalized to all the other type mismatch suggestions?
That's a good question. It was mostly an experiment to see if this specific issue can be solved with .
Change:
run: src/ci/scripts/install-msys2.sh <<: *step <del> - name: install MSYS2 packages run: src/ci/scripts/install-msys2-packages.sh <<: *step </del> - name: install MinGW run: src/ci/scripts/install-mingw.sh <<: *step

Discussion:
On 2019-10-24 we had a CI outage due to the ca-certificates msys2 package being broken. The hack implemented (:heart:) is to download an older, known good package beforehand and install it after msys2 updated its packages. Once is fixed we should revert the hack, but I think at this point it's worth investing in vendoring msys2 as a whole.
msys2 is using and other tools from archlinux distro. Arch Linux provides per-day official repositories snapshots. User can "pin" to a specific date. I think it is possible to reuse that mechanism to vendoring msys2 as a whole, by providing a mirror of a specific date's version. See here for more descriptions .
that would be nice but msys doesn't remove old packages from their repo so the mirror would be enormous. Search for in , only those packages take dozens of GiB. Also extracting it from archive would make CI a bit faster because you won't be modifying thousands of small files over and over. On Linux that is not a problem but working through cygwin emulation a bit struggles on this part.
No update on this, planning to discuss what to vendor at the all hands.
At the last infra meeting we decided a good step is to move towards using the pre-installed msys2 packages. In theory this is as simple as removing the msys2 installation step and pointing things at the right location on the images in CI.
Change:
pub fn check_implementation_coherence_of(&self, trait_def_id: DefId) { // Unify pairs of polytypes. <del> self.iter_impls_of_trait(trait_def_id, |a| { </del> <ins> self.iter_impls_of_trait_local(trait_def_id, |a| { </ins> let implementation_a = a; let polytype_a = self.get_self_type_for_implementation(implementation_a);

Discussion:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.
Change:
"lazy_static", "libc", "measureme", <del> "once_cell", </del> "parking_lot 0.10.2", "rustc-hash", "rustc-rayon",

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(associated_consts)] #[derive(Clone, Copy, Debug)] struct Bar; const BAZ: Bar = Bar; #[derive(Debug)] struct Foo([Bar; 1]); struct Biz; impl Biz { const BAZ: Foo = Foo([BAZ; 1]); } fn main() { let foo = Biz::BAZ; println!("{:?}", foo); } </ins>

Discussion:
The following code produces an internal compiler error when compiled with rustc 1.8.0-nightly (2016-01-27) through the Rust playground: Here's a sample of the error output from the playground: The error occurs regardless of the type of the array's elements. The error seems to be related to the type of array constructor used, since the following code compiles just fine: The error does not occur when associated constants are not involved: Now with backtrace!
Change:
/// assert!(!(0.0..1.0).contains(&f32::NAN)); /// assert!(!(0.0..f32::NAN).contains(&0.5)); /// assert!(!(f32::NAN..1.0).contains(&0.5)); <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] fn contains<U>(&self, item: &U) -> bool where

Discussion:
I tried this code: Also godbolt link I expected to see this happen: I was trying this code to see what kind of assemble the compilers makes. I tried different optimize levels. I see with optimize levels and , that the bits are still there but not used in the function. function is self takes about 5 instructions and the code about 40 instruction, which is dead code. Instead, this happened: bits removed in all the optimize levels. I was using a similar code on a embedded device. FYI: It also happens with . Remove the before 247. I see this happen on stable and nightly both for x86_64 and thumbv6/v7.
This is, unfortunately, well known. and aren't necessarily smaller 'll be optimized out in (which is opt-level=2).
Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.
maybe to clarify. With opt_level the assembly of the generated function is fine and optimized. But the bits are not removed and not used. so I am not sure if will help in this case.
does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the output to just one function.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:bad input fn main() { Some("foo").unwrap_or(fail!("bad input")).to_string(); } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
impl<T: Generator<ResumeTy, Yield = ()>> Future for GenFuture<T> { type Output = T::Return; <ins> #[track_caller] </ins> fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> { // SAFETY: Safe because we're !Unpin + !Drop, and this is just a field projection. let gen = unsafe { Pin::map_unchecked_mut(self, |s| &mut s.0) };

Discussion:
I tried: I expected the seventh line to be the panic location, but I got this: <details<summaryWith <codeRUSTBACKTRACE=1</code</summary</details%20-%3E%20!%20%7B%0A%20%20%20%20panic!()%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20futures%3A%3Aexecutor%3A%3Ablockon(async%20%7B%20panic().await%20%7D)%3B%0A%7D%0A) (tried using nightly 2020-11-06 ) I can achieve the result I expected by implementing a manually: Output: %5D%0A%0Ause%20std%3A%3A%7B%0A%20%20%20%20future%3A%3AFuture%2C%0A%20%20%20%20pin%3A%3APin%2C%0A%20%20%20%20task%3A%3A%7BContext%2C%20Poll%7D%2C%0A%7D%3B%0A%0Astruct%20Panic%3B%0A%0Aimpl%20Future%20for%20Panic%20%7B%0A%20%20%20%20type%20Output%20%3D%20!%3B%0A%0A%20%20%20%20%23%5Btrackcaller%5D%0A%20%20%20%20fn%20poll(self%3A%20Pin%3C%26mut%20Self%3E%2C%20%3A%20%26mut%20Context%3C%27%3E)%20-%3E%20Poll%3CSelf%3A%3AOutput%3E%20%7B%0A%20%20%20%20%20%20%20%20panic!

()%0A%20%20%20%20%7D%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20futures%3A%3Aexecutor%3A%3Ablockon()%3B%0A%7D%0A) I noticed that (in the backtrace) the compiler generated a closure (?) for the , so may be related. modify labels: A-async-await A-attributes
This seems to be working correctly. The call to does not actually panic, so the does nothing. just returns a future that, when polled, will panic.
But I expect it to work further: automatically generates the I implemented manually, with on and the generated closure/. (Feature request) It's even better if could work on blocks as well.
Sorry for my wrong interpretation of this issue. But currently on s does nothing and compiles without warning, so maybe this is also a ?
Since the call to an can never panic (it always returns an ), I think forwarding the attribute to the returned closure would make sense. This would require impementing (if only on nightly), so that the desugaring can forward as needed.
Since this issue was classified as a feature request, I edited the title to make it clear.
Forwarding to the poll function does seem reasonable to me. any thoughts on this?
Forwarding to the generated future SGTM.
Change:
<ins> error: concrete type differs from previous defining opaque type use --> $DIR/issue-74280.rs:8:13 | LL |     let y = || -> Test { () }; |             ^^^^^^^^^^^^^^^^^ expected `i32`, got `()` | note: previous use here --> $DIR/issue-74280.rs:7:1 | LL | fn test() -> Test { | ^^^^^^^^^^^^^^^^^ error: aborting due to previous error </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
The backtrace suggests that ICE is caused by error formatting machinery. This is a corner case that should be fixed, but my original intention was to provide a concrete type. Sadly, it didn't work out either: results in: Will this be possible one day? My intuition tells me that the snippet above should work. Apologies if this is an improper place for such questions.
The original no longer ICEs since , however the following does Maybe a different ICE?
And the above no longer ICEs since
Change:
pub extern fn rust_begin_panic(_msg: core::fmt::Arguments, _file: &'static str, _line: u32) -> ! { <del> loop {} </del> <ins> unsafe { intrinsics::abort() } </ins> } ```

Discussion:
The following file, when compiled without optimizations, correctly generates an overflow check in : However, compiling with optimizations plus or generates code without the overflow check. However, if I move to a separate no_core crate like this, the issue disappears and the overflow check is generated:
noticed that my panic implementation () is UB according to LLVM (see ), so it optimizes the overflow check out on the assumption that it can never be triggered (since that would be UB). Replacing it with e.g. fixes the issue.
Change:
checksum = "dac1c663cfc93810f88aed9b8941d48cabf856a1b111c29a40439018d870eb22" dependencies = [ "cfg-if", <del> "libc 0.2.112", </del> <ins> "libc", </ins> "rand", "redox_syscall", "remove_dir_all",

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
} let cmd = match subcommand.as_str() { <del> "build" => Subcommand::Build { paths }, "check" => Subcommand::Check { paths }, </del> <ins> "build" | "b" => Subcommand::Build { paths }, "check" | "c" => Subcommand::Check { paths }, </ins> "clippy" => Subcommand::Clippy { paths }, "fix" => Subcommand::Fix { paths }, <del> "test" => Subcommand::Test { </del> <ins> "test" | "t" => Subcommand::Test { </ins> paths, bless: matches.opt_present("bless"), compare_mode: matches.opt_str("compare-mode"),

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim