jiebi/CodeConvo huggingface dataset:
Change:
<del> error[E0308]: mismatched types --> $DIR/issue-57611-trait-alias.rs:21:9 | LL |         |x| x |         ^^^^^ one type is more general than the other | = note: expected trait `for<'a> Fn<(&'a X,)>` found trait `Fn<(&X,)>` note: this closure does not fulfill the lifetime requirements --> $DIR/issue-57611-trait-alias.rs:21:9 | LL |         |x| x |         ^^^ error: implementation of `FnOnce` is not general enough --> $DIR/issue-57611-trait-alias.rs:21:9 | LL |         |x| x |         ^^^^^ implementation of `FnOnce` is not general enough | = note: closure with signature `fn(&'2 X) -> &X` must implement `FnOnce<(&'1 X,)>`, for any lifetime `'1`... = note: ...but it actually implements `FnOnce<(&'2 X,)>`, for some specific lifetime `'2` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Discussion:
Repro: Output:
cc
What's causing this is that we currently inspect the obligations in scope for obligations, but in this case the obligation is (which implies a obligation as a supertrait). This is expected but unfortunate, yes. We could probably fix this particular case in a relatively straightforward way by trying to upcast each pending obligation to a obligation.
I imagine that atm this could be worked around by changing: to
Today, this gives a completely different error about not implementing ...
Updated code to not give the unrelated error (by removing bounds everywhere), still gives the type must be known error.
This comes up for me fairly regularly. It would be really nice to fix it. (e.g., it came up recently in )
We discussed this in the types team 'backlog bonanza' meeting today. Our conclusion was that this is a "nice to have" and that directly fixing this issue felt like a types team FCP, because it's a tweak to the inference rules. TL;DR right now we say If there is some trait obligation , then we take the args from it seems reasonable to say If there is some trait obligation that implies (through the "invariants", in terms) , then we take the args from that would fix this example (types team FCP would be required). However, I believe that beyond this specific example, most people who wind up here are trying to do something a bit more sophisticated, such as having an argument that might be a closure but might not, or have extended varieties of closures (). It is possible that just making the above change would fix those problems, but it's likely that further changes would be required. Those scope feels like a lang-team initiative. Still may be worth making this change just to screen out the easy cases, mind you!
Change:
<ins> // revisions:cfail1 cfail2 // compile-flags: -Z query-dep-graph --crate-type rlib -C lto // build-pass #![feature(rustc_attrs)] #![rustc_partition_reused(module = "rlib_lto", cfg = "cfail2")] pub fn foo() {} </ins>

Discussion:
First compile is ok, after I modify some contents. It failed. I've to . Then works.
I don't know how to setup a minimal env to reproduce this. But I'd love to provide any info you needed.
cc Is this maybe related to ? (Although this sounds like the opposite of that, where it is missing the bit code.)
Some digging shows that this is a preexisting bug in rustc: I believe that this is only showing up now because Cargo is only just now passing
I've posted a fix for this at
Change:
ch } <ins> /// Remove all matches of pattern `pat` in the `String`. /// /// # Examples /// /// ``` /// #![feature(string_remove_matches)] /// let mut s = String::from("Trees are not green, the sky is not blue."); /// s.remove_matches("not "); /// assert_eq!("Trees are green, the sky is blue.", s); /// ``` /// /// Matches will be detected and removed iteratively, so in cases where /// patterns overlap, only the first pattern will be removed: /// /// ``` /// #![feature(string_remove_matches)] /// let mut s = String::from("banana"); /// s.remove_matches("ana"); /// assert_eq!("bna", s); /// ``` #[unstable(feature = "string_remove_matches", reason = "new API", issue = "72826")] pub fn remove_matches<'a, P>(&'a mut self, pat: P) where P: for<'x> Pattern<'x>, { use core::str::pattern::Searcher; let matches = { let mut searcher = pat.into_searcher(self); let mut matches = Vec::new(); while let Some(m) = searcher.next_match() { matches.push(m); } matches }; let len = self.len(); let mut shrunk_by = 0; // SAFETY: start and end will be on utf8 byte boundaries per // the Searcher docs unsafe { for (start, end) in matches { ptr::copy( self.vec.as_mut_ptr().add(end - shrunk_by), self.vec.as_mut_ptr().add(start - shrunk_by), len - end, ); shrunk_by += end - start; } self.vec.set_len(len - shrunk_by); } } </ins> /// Retains only the characters specified by the predicate. /// /// In other words, remove all characters `c` such that `f(c)` returns `false`.

Discussion:
Like , but doesn't result in any allocations. I started implementing this in but got stuck, mainly because of limitations in the APIs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// Divide `Duration` by `f32`. /// /// # Panics <del> /// This method will panic if result is not finite, negative or overflows `Duration`. </del> <ins> /// This method will panic if result is negative, overflows `Duration` or not finite. </ins> /// /// # Examples /// ```

Discussion:
Hello. I am diagnosing why I've got a wrong duration computed from Duration::fromsecsf32()... I tried this code: I expected to see an exact 30-second duration. Instead, I've got this: which is: 30 seconds and 1024 nanos. I dig deeper into rust code and I've prepared a sample code which is computing it based on the source code: As the result I've got: Instead of exact 30 seconds and 0 nanos.
?
Works on current stable and nightly: I mean, that this issue exist for that versions.
yep, I also confirmed on:
What is interesting the function: fromsecsf64 doesn't seem to have this problem... so a quick workaround would be use it and cast from f32 to f64
Extending(?) f32 to u128 gives this addition in 1024:
CC: CC: Adding authors ... guys please take a quick look if you have a time...
f32 will naturally have trouble representing all possible nanosecond values and so doing calculations in f64 may help here somewhat. However the most appropriate approach would be to decompose the float into the whole part and the fractional part and then operate on the two separately to produce the values necessary to create the . and may work sufficiently well for the purpose. EDIT: I think we would still need to be careful about how the nanosecond fraction is handled. We cannot simply multiply the number by and then convert to an integer, because is not capable of representing integers of such degree losslessly.
We cannot simply multiply the number by and then convert to an integer, because f32 is not capable of representing integers of such degree losslessly. Small correction: is represented exactly by , the problem is with . The closest float is , which results in the 1024 ns error. For example, would have produced an exact value. I would say such loss of precision is expected for and if you want exact values, you should use the integer based methods. So I don't think this issue should be marked as a bug. It could be worthwhile to improve the code by processing the fractional part separately, but note that it will not solve this issue fundamentally. We still have the issue of mapping at most 23 fractional bits into ~30 bits, e.g. calling would still result in an inexact result.

specifically may be representable exactly, but f32 cannot represent all integers exactly. Though maybe its not a huge deal if after we end up roundtripping back to the actual integer in all cases.
Argh, I forgot that the method is not available on , so the linked PR will not work out of box. UPD: I have implemented manual fraction/exponent splitting and their conversion to integers.
Change:
FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  <del> g++  </del> <ins> clang  </ins> make  file  curl 

Discussion:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…
Change:
<ins> error: trait objects cannot be used in patterns --> $DIR/issue-70972-dyn-trait.rs:6:9 | LL |         F => panic!(), |         ^ 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. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
<ins> error: trait objects cannot be used in patterns --> $DIR/issue-70972-dyn-trait.rs:6:9 | LL |         F => panic!(), |         ^ error: aborting due to previous error </ins>

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .
Change:
checksum = "4db52ee8fec06e119b692ef3dd2c4cf621a99204c1b8c47407870ed050305b9b" dependencies = [ "gimli", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "object", "tracing", ]

Discussion:
I tried this code: I expected to see this happen: map = {1: "a"} Instead, error happened: Sometimes it causes Segmentation fault: <!-- 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
Miri reports UB with the target in question: (sorry for reflexively blaming LLVM, it didn't deserve that)
The root cause is that the stdarch SIMD intrinsics are broken on big-endian targets. For now I've disabled the use of NEON in hashbrown on big-endian ARM: We should probably disable/de-stabilize the NEON intrinsics on big-endian targets. They are currently all producing incorrect results.
All of them, or specifically for ARM? (Not sure if we have stdarch support for any other big-endian target.) Is there an issue tracking that and explaining in a bit more detail how they are broken?
This only applies to arm & aarch64 targets. Here is the issue in stdarch:
Miri doesn't support the NEON SIMD intrinsics though. So if Miri reports UB then it seems there are other problems as well?
Some are implemented using the same intrinsics as portable-simd.
It's a combination of a few things: We are missing a check for the NEON implementation. All the NEON intrinsics we happen to use in hashbrown are implemented without LLVM builtins.
Ah so I guess what happens is that Miri correctly implements the portable SIMD intrinsics, but stdarch implements the NEON intrinsics on top of them and it's doing that incorrectly? Miri and codegen/LLVM are fine?
Yes, that's my understanding.
Change:
<ins> // Check what happens when `def` is used to define a function, instead of `fn` // edition:2021 #![allow(dead_code)] def foo() {} //~^ ERROR expected one of `!` or `::`, found `foo` //~^^ HELP write `fn` instead of `def` to declare a function 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Ideally the error message should suggest replacing or with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
New to rustc community and wants to contribute code. there any options to debug rustc which line of which file the error abort happens? can I dump the hierarchy tree for debugging use? C++ we usually use env for compiler debugging. How do rustc often use? Very newbie questions, thank you in advance.
label +E-easy +E-mentor Welcome to Rust! This might be some help -- This issue is very similar to , so take a peek at the diff there. IMO the following tokens are enough to check against function (Julia/JavaScript/etc) func (Go) fun (Kotlin) def (Python) Have fun! <3
Instructions -- Add a check if prevtoken is either ///etc Emit a message, something along the lines of "use instead of <prevtokento make a function" using , there are a few usages of this in the same file so those might be good examples. Add tests for this in -- Ideally each suggestion would have a test. Should be helpful to take as a reference
We can include if necessary.
Hi guys, another rust newbie looking for something easy to get started here. are you still on this or could go with my attempt here?

ypprog does seem to be active and it hasn't been that long, if you'd like you can pick another issue. =) Try going through the E-Easy and/or E-Mentor category for easy issues. However, to clarify, if an issue which is claimed doesn't seem to have any work done for a long period of time (A month or so is a good amount of time) -- Feel free to ping the assignee to confirm and handle it accordingly.
With these changes, I also think it is important to implement improved error messages for when a user puts the return type at the start of the function instead of the end. Given this code: The error output is:
I feel like adding might also be helpful for C++ developers :)
Is this still being worked on?
release-assignment
claim
Change:
} rustc_lexer::TokenKind::BlockComment { doc_style, terminated } => { if !terminated { <del> let msg = match doc_style { Some(_) => "unterminated block doc-comment", None => "unterminated block comment", }; let last_bpos = self.pos; self.sess.span_diagnostic.span_fatal_with_code( self.mk_sp(start, last_bpos), msg, error_code!(E0758), ); </del> <ins> self.report_unterminated_block_comment(start, doc_style); </ins> } // Skip non-doc comments

Discussion:
Given: The compiler says: This initially confused me quite a bit because I couldn't figure out why Rust wasn't seeing block comment terminator. Eventually, I realized that the line changed from being a commented out line, to starting a nested block comment. Since block comments nest in Rust, I'm used to commenting out blocks without worrying about what's inside of them which made this behaviour surprising. I'm not sure how practical it is, but it would be cool if we could check for comments like in block comments to suggest them as the source of the problem. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
LL | |         "" LL | |     } | |_____^ <ins> ... LL |       format_args!(hang!()); |                    ------- in this macro invocation </ins> help: you might be missing a string literal to format with | LL |     format_args!("{}", hang!());

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
} } else if let Some(body) = &arm.body { self.dcx().emit_err(NeverPatternWithBody { span: body.span }); <del> guard = None; </del> } else if let Some(g) = &arm.guard { self.dcx().emit_err(NeverPatternWithGuard { span: g.span }); <del> guard = None; </del> } // We add a fake `loop {}` arm body so that it typecks to `!`.

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)', 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [shallowlintlevelson] looking up lint levels for [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in cc
Change:
trait_name)); } ObligationCauseCode::FieldSized => { <del> err.note("only the last field of a struct or enum variant  may have a dynamically sized type"); </del> <ins> err.note("only the last field of a struct may have a dynamically sized type"); </ins> } ObligationCauseCode::ConstSized => { err.note("constant expressions must have a statically known size");

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
}, ProjectionElem::Field(field, fty) => { let fty = self.sanitize_type(place, fty); <ins> let fty = self.cx.normalize(fty, location); </ins> match self.field_ty(place, base, field, location) { Ok(ty) => { let ty = self.cx.normalize(ty, location);

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. --I included the (commented out) workaround I found in case it's helpful. uncomment for a different ICE (Likely a duplicate of ) <!-- 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 --
label +A-incr-comp
claim