jiebi/CodeConvo huggingface dataset:
Change:
CFG_THIRD_PARTY_OBJECTS_i686-pc-windows-gnu := crt2.o dllcrt2.o CFG_INSTALLED_OBJECTS_i686-pc-windows-gnu := crt2.o dllcrt2.o rsbegin.o rsend.o CFG_RUSTRT_HAS_STARTUP_OBJS_i686-pc-windows-gnu := 1 <del> # FIXME(#31030) - there's not a great reason to disable jemalloc here CFG_DISABLE_JEMALLOC_i686-pc-windows-gnu := 1 </del>

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
} #[instrument(skip(self), level = "trace")] <del> fn opaque_ty_origin_unchecked(&self, def_id: LocalDefId, span: Span) -> OpaqueTyOrigin { </del> <ins> pub fn opaque_ty_origin_unchecked(&self, def_id: LocalDefId, span: Span) -> OpaqueTyOrigin { </ins> let origin = match self.tcx.hir().expect_item(def_id).kind { hir::ItemKind::OpaqueTy(hir::OpaqueTy { origin, .. }) => origin, ref itemkind => {

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
use rustc_middle::ty::{self, Binder, Ty}; use rustc_span::symbol::{kw, sym}; <ins> use rustc_middle::ty::subst::GenericArgKind; </ins> use std::iter; impl<'a, 'tcx> FnCtxt<'a, 'tcx> {

Discussion:
can easily be converted to , but we give a somewhat opaque E0308 when with the following situation: This results in: Which is not totally clear to people who do not understand the trait and/or do not know that it is implemented for these types. We should suggest that the user use to convert between these types. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
only works for and not for There are a couple of options I thought about, if there is a better one i'd be happy to use it: tell the user to pass a instead of a and use try to find where the parameter comes from and tell the user to remove the & sign and use if this is the last instance where the was used just handle the cases in which a is passed try to find a Copy or Clone impl on the struct and suggest to use it and use (this one seems like the most unsafe for arbitrary types, but in this particular case it would work) sorry for the inconvenience, I am new to rustc and I am currently trying to get started with this issue.
another option that would remain more local than finding where the was constructed is to try and suggest for that case in particular. Having said that, finding where the was constructed would be great because it's a type that is almost always wrong to use, unless it comes from a place where you end up with that because of type params (like a hashmap or another container), so it'd be good to lead people towards better code. What you can do is indeed split your work and focus on making the case work on its own PR, and then follow up with an attempt to handle .
Change:
Span::new(BytePos(start_of_next_point), end_of_next_point, sp.ctxt(), None) } <ins> /// Returns a new span to check next none-whitespace character or some specified expected character /// If `expect` is none, the first span of non-whitespace character is returned. /// If `expect` presented, the first span of the character `expect` is returned /// Otherwise, the span reached to limit is returned. pub fn span_look_ahead(&self, span: Span, expect: Option<&str>, limit: Option<usize>) -> Span { let mut sp = span; for _ in 0..limit.unwrap_or(100 as usize) { sp = self.next_point(sp); if let Ok(ref snippet) = self.span_to_snippet(sp) { if expect.map_or(false, |es| snippet == es) { break; } if expect.is_none() && snippet.chars().any(|c| !c.is_whitespace()) { break; } } } sp } </ins> /// Finds the width of the character, either before or after the end of provided span, /// depending on the `forwards` parameter. fn find_width_of_character_at_span(&self, sp: Span, forwards: bool) -> u32 {

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim
Change:
<ins> // only-x86_64 // Make sure rustc doesn't ICE on asm! when output type is !. #![feature(asm)] fn hmm() -> ! { let x; unsafe { asm!("/* {0} */", out(reg) x); //~^ ERROR cannot use value of type `!` for inline assembly } x } fn main() { hmm(); } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Somewhere during compilation of this code, LLVM's ). Because of that, rustccodegenllvm::asm::inlineasmcall , and the parent function then .
I a statement to log the function type and constraints string passed to LLVM:
claim
Change:
} function addSearchOptions(crates) { <del> var elem = document.getElementById('crate-search'); </del> <ins> var elem = document.getElementById("crate-search"); </ins> if (!elem) { return;

Discussion:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!
Change:
// shaves an instruction off those code paths (on x86 at least). assert!(capacity <= usize::MAX - max_leb128_len()); <del> let file = File::create(path)?; </del> <ins> // Create the file for reading and writing, because some encoders do both // (e.g. the metadata encoder when -Zmeta-stats is enabled) let file = File::options().read(true).write(true).create(true).truncate(true).open(path)?; </ins> Ok(FileEncoder { buf: Box::new_uninit_slice(capacity),

Discussion:
started ICEing between nightly-2022-07-15 and nightly-2022-07-16, looking at diff it's probably , so ? <!-- 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
Looks like file is created write-only here: and is trying to be read here: I haven't contributed here yet, but it looks to me like instead of would fix this. Should I make a PR? ~I unfortunately don't have a computer good enough to compile locally atm.~
That should probably works, , but looks little hacky.
I agree it looks wonky, but the only other option would be storing the path in and then creating a new read handle on it later, AFAIK. <-- I like this option much less.
bash mvce `
Change:
<ins> #![feature(generic_const_exprs)] #![allow(incomplete_features)] pub trait X { const Y: usize; } fn z<T>(t: T) where T: X, [(); T::Y]: , { } fn unit_literals() { z(" "); //~^ ERROR: the trait bound `&str: X` is not satisfied } fn main() {} </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering 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<summary<strongBacktrace</strong</summary<p</p</details
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
<ins> fn foo(s: &i32) -> &i32 { let xs; xs } fn main() { let y; if foo == y {} //~^ ERROR binary operation `==` cannot be applied to type } </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also fails for every comparison of and
I found another potentially related weirdness: This fails with: But this (without the argument) fails with a different error, even though there should be no difference as is not used: EDIT: Apparently this is intended behavior, see .
searched nightlies: from nightly-2019-01-01 to nightly-2020-10-13 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Darn, is it really the bitcode commit again? Or did it happen sometime around then? Cc
This bisection is incorrect due to:
Marking this as P-
claim
You have to write if you want to assign this issue.
Thanks bro. claim
Change:
<ins> // This used to compile the future down to ud2, due to uninhabited types being // handled incorrectly in generators. // compile-flags: -Copt-level=z -Cdebuginfo=2 --edition=2018 // run-pass #![feature(async_await)] #![allow(unused)] use std::future::Future; use std::task::Poll; use std::task::Context; use std::pin::Pin; use std::rc::Rc; struct Never(); impl Future for Never { type Output = (); fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> { Poll::Pending } } fn main() { let fut = async { let _rc = Rc::new(()); // Also crashes with Arc Never().await; }; let _bla = fut; // Moving the future is required. } </ins>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
self.parse_method(attrs, visa) } <ins> fn complain_if_pub_macro(&mut self, visa: Visibility, span: Span) { match visa { Public => { self.span_err(span, "can't qualify macro invocation with `pub`"); self.span_help(span, "try adjusting the macro to put `pub` inside  the invocation"); } Inherited => (), } } </ins> /// Parse a method in a trait impl, starting with `attrs` attributes. pub fn parse_method(&mut self, attrs: Vec<Attribute>,

Discussion:
Hey, I have an issue on my macros use. The source code of my macro is . I can't put the pub keyword and if I call my macro like this : The methods aren't public. Am I doing something wrong or is it a compiler's bug ? Thanks in advance.
Any news on it ?
Related?
I think.
I just encountered this. I can reproduce it with:
Now let's just hope it'll be fixed sooner or later !
Hm, what should actually mean? A macro in item position can expand to zero or more items. Should the qualifier apply to all of them, or should it be an error to use it with a multi-item macro? We might want to forbid in this position for 1.0, and come back to the issue later. I had a design for that I think would be rather nice. The current workaround is to write The precise syntax is up to the macro author and can accommodate multiple items. This workaround would be less annoying if we had a "0 or 1" repeat operator in macros.
Could you be a little more explicit about the workaround - I can't seem to get it to work.
from the compiler itself. looks better, with less duplicated code.
Thanks for the examples. If I understand them correctly (neither of which generate forms, iiuc), I should be matching on and inserting a literal in the expansion, but does not seem to work :
It works for me on rustc 1.0.0-dev ( 2015-02-16). The playpen is just to have my fix for .
Thanks for the confirmation. I'll be looking forward to a new nightly for once :)
Change:
/// If true, the lifetime will be fully elided. use_span: Option<(Span, bool)>, }, <del> NamedArgumentUsedPositionally(Span, Span, String), </del> <ins> NamedArgumentUsedPositionally(Option<Span>, Span, String), </ins> } /// Lints that are buffered up early on in the `Session` before the

Discussion:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

<!-- 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. --Upon running , the compiler panics when having as a dependency. and complete without error. Probably this is related to ? <!-- 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. --: and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p: </p</details
Appears to be a duplicate of
Change:
|                  ^^ error[E0308]: mismatched types <del> --> $DIR/if-let-typo.rs:6:12 | LL |     if 3 = foo {} |            ^^^ expected integer, found enum `Option` | = note: expected type `{integer}` found enum `Option<{integer}>` error[E0308]: mismatched types </del> --> $DIR/if-let-typo.rs:6:8 | LL |     if 3 = foo {} |        ^^^^^^^ expected `bool`, found `()` <ins> | help: you might have meant to use pattern matching | LL |     if let 3 = foo {} |        ^^^ </ins> error[E0308]: mismatched types <del> --> $DIR/if-let-typo.rs:8:8 </del> <ins> --> $DIR/if-let-typo.rs:7:8 </ins> | LL |     if Some(3) = foo {} |        ^^^^^^^^^^^^^ expected `bool`, found `()`

Discussion:
I thought this code would provide one of the nice suggestions that implemented in , but it doesn't. (By the way, making a reference to will give an ICE because of .) () Errors:
Reopening as per
This is fixed in beta now: It is still quite verbose (too many errors), but we lead people in the right direction.

: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed in
Cc
Related: this code should probably have a suggestion for (): Currently it produces:
Minimized (): I think this might be caused by the lifetimes.
Never mind! This causes it too, with no lifetimes (): EDIT: removed the type aliases EDIT 2: changed to to make it clearer that they don't need to be the same type EDIT 3: shortened names, removed comment
Assigning and removing as .20.3D.20.2E.2E.2E.60.20expression.E2.80.A6) in the prioritization working group.
Further minimized to this (): Having be a or produces the ICE, but making it an owned does not produce the ICE.
causes the operands to be typechecked twice: I think this has side effects that are causing problems by being applied twice. Commenting out the second makes the ICE go away, but I'm not sure what the best approach for a proper fix is. The effect on the UI suite is rather low: (It still emits this error:)
I tried a couple of things but it seems to me that you hit the nail in the head and we just need to remove the branch. this is caused because one side is seen to be while the other is seen to be or (depending on the case). This is a problem because the left hand side expression should in reality be a pattern instead, but there's no utility to build a pattern from an expression: patterns are built during parsing (due to differences like, being a valid thing there). Because of that it'll be very hard to make the suggestion happen for those cases, much harder than for the ones we already handle.
I think I just found a smaller example (granted, it's not valid code any more, but how is one supposed to know that in case of ICE? ;-) ): (If that's not the same error I'm happy to open a new ICE issue, but to me it looks the same, with all the , the panic at and the conditional destructuring in a loop).
Change:
} add_doc_fragment(&mut out, new_frag); } <ins> out.pop(); </ins> if out.is_empty() { None } else { Some(out) } }

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
use std::{char,str}; use std::convert::TryFrom; <ins> use std::str::FromStr; </ins> #[test] fn test_convert() {

Discussion:
I'm not sure if this is an oversight. But the implementation should be trivial. I'll add tests and implement it, if it is fine.
Strings aren't indexable and .len() doesn't count the number of chars. :smile: What comes to mind first is an iterator inspecting the two first chars:
xD I didn't test my code, but you get the gist. I had a impl at first, but then edited it
cc
Triage: this has not been .
PRs welcome!
I can take this. I was also thinking of adding a impl for , but unsure if it would be better to wait for to get closer to stabilization and use that instead of adding another empty enum to std
wait, that wouldn't work bc of lifetime issues regardless, right? :(