jiebi/CodeConvo huggingface dataset:
Code change:
<ins> warning: the feature `inherent_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/variance-computation-requires-equality.rs:3:12 | LL | #![feature(inherent_associated_types)] |            ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Code change:
<ins> warning: the feature `inherent_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/variance-computation-requires-equality.rs:3:12 | LL | #![feature(inherent_associated_types)] |            ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

Related discussion:
text: Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in
Code change:
} #[cfg(not(target_vendor = "win7"))] <del> #[link(name = "synchronization")] </del> <ins> // Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. #[cfg_attr( target_arch = "x86", link( name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib", import_name_type = "undecorated" ) )] #[cfg_attr( not(target_arch = "x86"), link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") )] </ins> extern "system" { pub fn WaitOnAddress( address: *const c_void,

Related discussion:
text: The following GitHub action fails with nightly-2024-02-27 but passes with nightly-2024-02-26 for (I believe) any project with a file: The error I got is the following: This only affects x8664-pc-windows-gnu (not MVSC), and switching from to fixes the issue. I have reproduced the issue in I may end up deleting that repo in the future, so for posterity, I've included all the code below: <details<summaryExample project to reproduce the issue:workflows (See above) src </detailsThe original discovery of this issue is reported in Running yielded the following for the latest nightly version without the issue: Running on three versions with_ the issue (the next nightly version, the latest nightly version, and the current beta) yielded the following: This issue is not present in rustc 1.77.2 (the latest stable version).
The imports should mostly be shared between msvc and gnu so the fact the targets differ is a bit puzzling. My hypothesis would be that mingw on Windows Server 2019 is using an older version of an import library that maps one or more functions to the wrong DLL. Specifically I think this could be caused by the import library. cc in case you've heard of anything like this before
I doubt it's a problem with the old MinGW-w64; in that case, the program would fail to link. I helped with a similar issue recently, and it was caused by the wrong being loaded. There are two DLLs called that, and if a manifest is not provided, Windows will load the wrong one:
Hm... I ran on both windows-2019 and windows-latest and the import tables do look different (see ). <details<summarywindows-2019</summary</details<details<summarywindows-latest</summary</detailsNote that is listed under in windows-2019 but it's more correctly listed under in windows-latest.
Yeah, that is probably the culprit but mingw-w64 links from since mid 2016: If it's caused by miingw-w64 toolchain preinstalled on image it must be terribly out of date.
Quite possibly it is that out of date. The other explanation would be it's coming from somewhere else, which Is a bit worrying.
Code change:
} #[cfg(not(target_vendor = "win7"))] <del> #[link(name = "synchronization")] </del> <ins> // Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. #[cfg_attr( target_arch = "x86", link( name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib", import_name_type = "undecorated" ) )] #[cfg_attr( not(target_arch = "x86"), link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") )] </ins> extern "system" { pub fn WaitOnAddress( address: *const c_void,

Related discussion:
text: Based on , my first impression is that mingw-w64 isn't preinstalled on the image. Unless Windows Subsystem for Linux is relevant, I assume that the mingw-w64 toolchain is installed as part of the run of .
Various tools like Perl might come with GCC. Could you determine location of and ?
I'm not sure. I've only been able to reproduce this via a GitHub action, not on my own machine, although I might be able to use something like to explore around. Alternatively, I could just run a fixed list of commands. If there's a set of commands I can run to answer any questions you have, please let me know. I'm not sure how the Rust toolchain determines which version of to run when building Rust code, but that seems like something you might know. EDIT: Based on your question, I might need to just run with the two applications you asked about. EDIT2: and are both in according to .
Here are the versions of based on running :
Thanks, apparently there was a bug in mingw-w64 fixed in 2020: IIRC this toolchain is older than that so it's indeed a bug in mingw-w64 shipped with this .
Oh, weird. also comes shipped with so this image generally has up-to-date packages. I also didn't see mingw or mingw-w64 mentioned anywhere in its README, so now I'm wondering if there's a bug in the image itself. I expect this means that no action will be needed for this particular issue unless we want to be more robust to bad environments like this. EDIT: It looks like it's defined here: EDIT2: It was documented after all. I had to search for "gcc", not "mingw".
I was rather confused because states that the latest version from the 8.x series is 8.0.2, but the version installed of in the the Windows 2019 image is 8.1.0, which seems like it shouldn't exist. However, based on the releases of , the number after the is probably what's important, which means that we're on version 6.0.0, which is indeed before the fix. I might ask in the project to see if it's worth updating mingw64 for this reason.
Code change:
} #[cfg(not(target_vendor = "win7"))] <del> #[link(name = "synchronization")] </del> <ins> // Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. #[cfg_attr( target_arch = "x86", link( name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib", import_name_type = "undecorated" ) )] #[cfg_attr( not(target_arch = "x86"), link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") )] </ins> extern "system" { pub fn WaitOnAddress( address: *const c_void,

Related discussion:
text: EDIT: Filed Depending on their response, if they decide not to update, it's possible could be fixed instead to stop trying to install Rust over an incompatible version of MinGW.
For some reason, my original issue description code snippet mentioned instead of . I think that's because I copy/pasted the wrong version, when I was seeing whether the workaround worked (which I believe it did). I apologize if that caused any confusion. I've now edited the description to fix this mistake.
Given that seems to be in progress and would close this issue, I mentioned that in for extra transparency.
Thank you for all your help on this! It's awesome that all this happened in only 4 days. I can confirm on my end that this issue is now fully resolved on the latest nightly release of Rust (2024-04-19).
Code change:
self.pos } <ins> // This is only used by a test which asserts that the initialization-tracking is correct. #[cfg(test)] pub fn initialized(&self) -> usize { self.initialized } </ins> #[inline] pub fn discard_buffer(&mut self) { self.pos = 0;

Related discussion:
text: I tried this code: I expected to see this happen: Instead, this happened: The problem doesn't occur with optimization enabled. It most recently worked on: Also fails on: modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for reporting this! This is an issue with a debug build so it's unlikely to be prioritized high but I'm interested in helping out because this is very goofy. The slow code here is the Iterator impl on slices. I think in the last stable release we switched the implementation of BufReader to eventually use ReadBuf, and the slow code is ReadBuf initializing the remaining uninitialized capacity. It does this by iterating over a slice, and that iteration is the slow bit. What I don't get here is why we need to initialize at all. That doesn't seem right.
WG-prioritization assigning highest priority since this looks a pretty visible runtime perf. regression (). If the assessment should be revised, please feel free to comment. label -I-prioritize +P-critical i-slow
I've tried bisecting with and feeding this command: . Regression seems to be in and confirm <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
:joy: I was so sure this wasn't my fault. More fool me for not bisecting it myself.
(This probably shows an opportunity to add a benchmark to the newly-established "runtime benchmarks" (rather than the compilation-time benchmarks that has classically focused on...)
After sleeping on this, I realized that there's no real reason to expect the worlds-worst-memset code which is the source of the slowdown to be totally optimized out with . And of course it isn't. This is also a substantial regression with optimizations.
Code change:
self.pos } <ins> // This is only used by a test which asserts that the initialization-tracking is correct. #[cfg(test)] pub fn initialized(&self) -> usize { self.initialized } </ins> #[inline] pub fn discard_buffer(&mut self) { self.pos = 0;

Related discussion:
text: Here's a version of the original program that's touched up a bit: On 1.63 I see runtime ~0.43 s, and on 1.64 ~4.8 s. So we have a slowdown of around 10x, though I suspect that number could be ratcheted up higher.
claim
Awesome, thanks for the really quick fix!
Code change:
struct Bar; impl Foo for Bar {} // error: `Foo` is not a trait <ins> fn baz<T: Foo>(t: T) {} // error: `Foo` is not a trait </ins> ``` Another erroneous code example: ```compile_fail,E0404 <del> struct Foo; </del> <ins> type Foo = Iterator<Item=String>; </ins> <del> fn bar<T: Foo>(t: T) {} // error: `Foo` is not a trait </del> <ins> fn bar<T: Foo>(t: T) {} // error: `Foo` is a type alias </ins> ``` Please verify that the trait's name was not misspelled or that the right

Related discussion:
text: I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).
Code change:
<ins> #![feature(allow_internal_unstable)] // Macro to help ensure CONST_ERR lint errors // are not silenced in external macros. // https://github.com/rust-lang/rust/issues/65300 #[macro_export] #[allow_internal_unstable(type_ascription)] macro_rules! static_assert { ($test:expr) => { #[allow(dead_code)] const _: () = [()][!($test: bool) as usize]; } } </ins>

Related discussion:
text: The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.
Code 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. static FOO: &'static [u8] = bytes!("hello, world"); pub fn main() { let b = match true { true => bytes!("test"), false => unreachable!() }; assert_eq!(b, "test".as_bytes()); assert_eq!(FOO, "hello, world".as_bytes()); } </ins>

Related discussion:
text: With landed, the lifetime of is now problematic. Specifically, the following used to work and now fails: The lifetime of is now limited to that branch of the match, so it doesn't live long enough to be assigned to . I'm not sure if this means lifetimes need to change. The other option is that needs to return a . Unfortunately, the only way to do that right now is to make it equivalent to , which makes it no longer usable as the value of a constant (e.g. ). I'm thinking the right solution is to make it legal for me to say . I can type that right now, but the lifetime seems to be wholly ignored, as I get the exact same error with the following as I do with the example above: If becomes a valid expression with the lifetime, then could start evaluating to that and everything should work as expected. Furthermore, it would be nice (but perhaps not required) if , where all elements are compile-time constants, would implicitly be given the lifetime.
/cc
Yeah, this is kind of annoying. I worked around it in one specific case by having bytes! expand as follows: I certainly think one should be allowed to write a concrete lifetime as part of a slice or borrow expression, and ought to be legal -- we'll obviously have to impose more stringent constant-related rules. In the short term, we could adjust to expand in the pattern I showed above. What was unclear to me was whether this is sufficient workaround, or whether we'll want something more general. Interestingly, even if we used full inference, the expression you gave above would be illegal unless we introduce a special case for static byte strings, because it generates a conditional temporary (only on one arm of the match) and we can't handle the cleanup for such a case without zeroing, which we plan to remove (well, I guess we could also have a special case for temporary types [like ) that do not require drop glue, but I'd rather not).
Perhaps the simplest fix for now is to adjust the macro itself to expand to a static item as I showed. I should probably have done that more generally but I was ready to land that expletive branch already.
Won't that prevent from being able to expand to a static?
I already adjusted like that and is correct, it prevents , which is definitely already used in our codebase.
Ah, unfortunate.
Code 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. static FOO: &'static [u8] = bytes!("hello, world"); pub fn main() { let b = match true { true => bytes!("test"), false => unreachable!() }; assert_eq!(b, "test".as_bytes()); assert_eq!(FOO, "hello, world".as_bytes()); } </ins>

Related discussion:
text: (I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc
Code 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. #[macro_export] macro_rules! m { () => { use $crate; } } </ins>

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
<del> Subproject commit c388361cc2db82568d5e90fefea864f0af8d35e9 </del> <ins> Subproject commit a0ba079b6af0f8c07c33dd8af72a51c997e58967 </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Cc The error is with the following backtrace
Ah but further up the call stack we have so I think this will be fixed by
Code change:
.map(|(id, title, items)| LinkBlock::new(Link::new(id, title), "", items)) .collect(); sidebar_assoc_items(cx, it, &mut blocks); <ins> if !t.is_object_safe(cx.tcx()) { blocks.push(LinkBlock::forced( Link::new("object-safety", "Object Safety"), "object-safety-note", )); } </ins> blocks.push(LinkBlock::forced(Link::new("implementors", "Implementors"), "impl")); if t.is_auto(cx.tcx()) { blocks.push(LinkBlock::forced(

Related discussion:
text: So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".