jiebi/CodeConvo huggingface dataset:
Change:
fn visit_item(&mut self, item: &'tcx Item) { let mut item_hir_id = None; self.lctx.with_hir_id_owner(item.id, |lctx| { <del> if let Some(hir_item) = lctx.lower_item(item) { item_hir_id = Some(hir_item.hir_id); lctx.insert_item(hir_item); } </del> <ins> lctx.without_in_scope_lifetime_defs(|lctx| { if let Some(hir_item) = lctx.lower_item(item) { item_hir_id = Some(hir_item.hir_id); lctx.insert_item(hir_item); } }) </ins> }); if let Some(hir_id) = item_hir_id {

Discussion:
The following breaks on nightly (see ) With: CC: dtolnay/async-trait
Reduced:
Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:
The reason this is happening is that the desugared version of applies all in-scope lifetimes to the returned existential type, which in this case is creating , which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is but can refer to lifetimes originating from the impl header. cc who may have opinions.
Hmm wouldn't you expect the nested to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?
The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested isn't part of the . The bug I was focusing on is better illustrated by this example: which produces this error: This is because the code is transformed into and in that case does not refer back to the usage from the header.
I see. Indeed, I would expect that, internally, we'd have some way to refer back to the from the impl header. I believe this should be possible, no? In particular, the in impls expands (internally) to for some integer N, which I believe is basically treated like any other named lifetime.
Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.
I was looking and I think the bug lies here: Probably needs to be a instead, or we need to use something else for this purpose.
A closer reading suggests I was mistaken. The lifetimes from the impl should show up in -- includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.
OK, no, I was correct. When processing impl items, we convert the lifetimes into entries. EDIT: Er, I'm still not entirely sure. Reading more. =)
OK, I have a fix for the method issue, but not the nested async fn item issue.

I forked off for the method issue
I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.
but if you have a chance to investigate, would be appreciated
Presumably the problem is that doesn't "reset" the vector -- it only seems to extend it...
Indeed, in-band lifetimes are broken in the same way. This fails to compile ():
Working on a possible fix
Yep, have a fix.
Inband lifetimes looks similar to fwiw
thanks
Change:
This operator is called 'modulo', and it returns the remainder of a division. By taking the modulo of the result of `rand::random()`, we're limiting the values to be between 0 and 99. Then, we add one to the result, making it from 1 <del> to 100. </del> <ins> to 100. Using modulo can give you a very, very small bias in the result, but for this example, it is not important. </ins> Let's try to compile this using `cargo build`:

Discussion:
cc This part is somewhat confusing: My suggestion is: either mention that samples the whole range of int and you use modulo to narrow the range. Or use the function. This way you also don't get modulo bias.
cc (If you want to mention someone, use )
Done, thanks.
I pulled this up in the original review: As you can see the modulo bias is miniscule (even on 32-bit platforms it is only billionths).
The introduction of modulo bias is not the main issue. The issue is that I, as a newbie, got confused by the %100 trick, so maybe it needs some more explanation.
I agree. should also be the recommended way to generate a random number in a range. If it will be expanded on later in the guide, that's fine, but then some more explanation here could be nice. If you surround your code with backticks, like then you'll get code sytax
Change:
| LL | #[derive(crate::my_macro)] |          ^^^^^^^^^^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/macro-namespace-reserved-2.rs:50:10 | LL | #[derive(crate::my_macro)] |          ^^^^^^^^^^^^^^^ = help: add as non-Derive macro `#[crate::my_macro]` </ins> error: cannot find macro `my_macro_attr` in this scope --> $DIR/macro-namespace-reserved-2.rs:28:5

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
import os import sys import functools <del> import resource </del> STATUS = 0

Discussion:
check- uses Unix-only module , runs and therefore fails on Windows Workaround: use instead of cc
Oof, sorry! Having a look now
What version of python and windows are you on? I was fairly sure that I confirmed this did something reasonable on not-posix, but I do not in fact have a windows box to test on. I'm kinda confused about how the builders are working right now.
msys2 x64 on Windows 7 Python 2.7.9
Change:
// revisions: hexagon_unknown_none_elf // [hexagon_unknown_none_elf] compile-flags: --target hexagon-unknown-none-elf // [hexagon_unknown_none_elf] needs-llvm-components: hexagon <del> // revisions: i386_apple_ios // [i386_apple_ios] compile-flags: --target i386-apple-ios // [i386_apple_ios] needs-llvm-components: x86 </del> // revisions: i586_pc_nto_qnx700 // [i586_pc_nto_qnx700] compile-flags: --target i586-pc-nto-qnx700 // [i586_pc_nto_qnx700] needs-llvm-components: x86

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.
Change:
unsafe { c::GetConsoleMode(handle, &mut mode) != 0 } } <del> fn write(handle_id: c::DWORD, data: &[u8]) -> io::Result<usize> { </del> <ins> fn write( handle_id: c::DWORD, data: &[u8], incomplete_utf8: &mut IncompleteUtf8, ) -> io::Result<usize> { if data.is_empty() { return Ok(0); } </ins> let handle = get_handle(handle_id)?; if !is_console(handle) { let handle = Handle::new(handle);

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Program does not panic. Instead, this happened: Program panics with the error . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.
Change:
--> $DIR/needs-feature.rs:9:26 | LL | struct A<const N: usize, T=u32>(T); <del> |         -----------------^----- help: reorder the parameters: lifetimes, then types, then consts: `<T, const N: usize>` </del> <ins> |         -----------------^----- help: reorder the parameters: lifetimes, then types, then consts: `<T = u32, const N: usize>` </ins> error: aborting due to previous error

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
krates .iter() .map(|s| { <del> format!("<li><a href="{}index.html">{}</li>", ensure_trailing_slash(s), s) </del> <ins> format!( "<li><a class="mod" href="{}index.html">{}</a></li>", ensure_trailing_slash(s), s ) </ins> }) .collect::<String>() );

Discussion:
Rustdoc highlights most links in blue, for example module links: ! But it does not highlight the links on the docs index page: ! Generally links are highlighted in blue (or some other color) on websites and the rest of Rustdoc highlights links so it would be more consistent to highlight these links. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: C-bug C-enhancement T-rustdoc
Where did you find that link?
The index page is and the page that shows the modules is
Do you know how to get to the index page () with docs for other crates? I can't seem to find the "List of all crates" in docs for other projects.
I don't think this is actually generated by rustdoc. This looks like bootstrap is passing .
In which case this should be a feature request for bootstrap, not a bug report for rustdoc.
Hmm, but it's generated by Rustdoc here:
Oh interesting. It's still not on by default, you need to pass , but it's definitely a rustdoc issue.
claim
Change:
let stdcppname = if target.contains("openbsd") { // llvm-config on OpenBSD doesn't mention stdlib=libc++ "c++" <ins> } else if target.contains("freebsd") { "c++" </ins> } else if target.contains("netbsd") && llvm_static_stdcpp.is_some() { // NetBSD uses a separate library when relocation is required "stdc++_pic"

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:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> use std::libc; </del> use std::io::IoError; <ins> use std::libc; use std::ptr; </ins> use std::rt::rtio::RtioTTY; use homing::{HomingIO, HomeHandle};

Discussion:
I'm on OSX 10.8.4, x8664, latest Rust on master. And to head off any concerns about my file handle limits: I ran into this when stress-testing my web sockets library. After just a couple hundred connections, some connections were being refused at random. The only thing I could see was some output with saying . I've come up with a smaller test case that brings this out with some spectacular errors: Fails less often with 100-200 connections. The errors are different every time I run this with . Here's the end of one run: Another: Another: And lastly:
cc
Oh dear that's bad, thanks for the small issue! I will definitely investigate.
What is the result of though? Just calling is only the maximum file size (unless OSX is different).
you're right! So I set it to a higher value and things seem fine now. Sorry about that. Though, It's still a surprising way for the runtime to fail, and clearly something is still wrong there.
Despite OSX having small file descriptor limits, this is a serious bug that I'd like to address with the runtime. Something funny is going on.
With applied, I am unable to reproduce this on OSX. I am not convinced that it fixes anything, but I'm no longer seeing any scary assertions.
I take that back, I was using , not (silly me)
I attempted to debug this issue on linux, and I quickly ran into two problems. The first is an assertion fixed by , and the other is filed as Sadly none of this seems related to the assertions on OSX, so I'll continue to investigate there. If only OSX still had valgrind...
Change:
impl<'tcx> MirPass<'tcx> for ByMoveBody { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut mir::Body<'tcx>) { <ins> // We only need to generate by-move coroutine bodies for coroutines that come // from coroutine-closures. </ins> let Some(coroutine_def_id) = body.source.def_id().as_local() else { return; };

Discussion:
Something is still wrong w/ async call shims. I think I'm not doing the transform correctly or something. Putting this up so I don't forget about it, but I'll fix it.
ohhhhh lol it's drop glue. Huh.
Oh hell yes this is actually totally wrong wtf:
Change:
} ExprKind::Repeat { value, count } => { let value_operand = unpack!(block = this.as_operand(block, value)); <del> let count = this.as_constant(count); </del> block.and(Rvalue::Repeat(value_operand, count)) } ExprKind::Borrow { region, borrow_kind, arg } => {

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
<ins> #![deny(warnings)] #![doc(test(""))] //~^ ERROR `#![doc(test(...)]` does not take a literal //~^^ WARN this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! fn main() {} </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. --This is a fuzzed test case, found with and minimized with , and did not find any related issues. I was able to reproduce with a compiler I compiled from . <!-- 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 --<!-- TRIAGEBOT_END --
claim
label +S-bug-has-mcve
Change:
/// Adds the created metadata nodes directly to the crate's IR. pub fn create_captured_var_metadata<'blk, 'tcx>(bcx: Block<'blk, 'tcx>, node_id: ast::NodeId, <del> env_data_type: Ty<'tcx>, </del> env_pointer: ValueRef, env_index: uint, captured_by_ref: bool,

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder
Change:
return None; } <del> if self.history.contains(&callee) { </del> <ins> if self.history.contains(&callee.def_id()) { </ins> return None; }

Discussion:
I tried this code with (, ; minimized and modified from 's ): I expected to see this happen: Successful compilation Instead, this happened: Compiler hangup <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summaryBacktrace</summary<pCaptured by a command in GDB:  </p</details
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
| DefKind::Impl { .. } | DefKind::Closure | DefKind::Generator => true, <del> DefKind::ConstParam | DefKind::ExternCrate </del> <ins> DefKind::ExternCrate </ins> | DefKind::Use | DefKind::ForeignMod | DefKind::ImplTraitPlaceholder

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. --Not sure how this passes the test suite :upsidedownface: Original code from reduced &lt;!-- 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. --: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongBacktrace&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
This is caused by The fix is to either enable in - this improves diagnostics but pessimizes compile times for successful compilations. do not use spans of const generic parameters from other crates in diagnostics - this makes diagnostics worse but optimizes compile times for successful compilations.
I can't reproduce this either locally or in playground.
Weird, I can still repro locally with and master :shrug:
mcve from a different file:
This is also weird for me to reproduce: I must be doing something wrong, both my and toolchains are the same rustc/cargo commits ( and ): a (or rustc) ICEs on that stdsimd repro a (or rustc) does not a ICEs (but not rustc)
Yeah, something is very weird. I didn't manage to properly this when I tried. I also failed to reproduce on playground or godbolt, but I have encountered maybe around 20 more or less similar files that hit this ICE when checking reports.
Same for me, found a nightly but failed with the CI artifacts. If somehow invoking differently manually or with/without rustup makes things work or fail, maybe the tool also invokes things in the way that doesn't repro...
I forgot to mention: this does also reproduce on master and reverting seems to fix the ICE indeed, as vadim suggested above.
I'm going to remove has-mcve since we're not sure why it sometimes doesn't ICE.
I think this is the better solution. Otherwise, we'll have more and more special cases in diagnostic code which is already very complex.
Couple more reproducers:
Change:
InternalSubsts::identity_for_item(tcx, def_id.to_def_id()), ), generics: tcx.generics_of(def_id), <ins> tcx, selftys: vec![], </ins> }; let prohibit_opaque = tcx .explicit_item_bounds(def_id) .iter() .try_for_each(|(predicate, _)| predicate.visit_with(&mut visitor)); debug!( <del> "check_opaque_for_inheriting_lifetimes: prohibit_opaque={:?}, visitor={:?}", prohibit_opaque, visitor </del> <ins> "check_opaque_for_inheriting_lifetimes: prohibit_opaque={:?}, visitor.opaque_identity_ty={:?}, visitor.generics={:?}", prohibit_opaque, visitor.opaque_identity_ty, visitor.generics </ins> ); if let Some(ty) = prohibit_opaque.break_value() { <ins> visitor.visit_item(&item); </ins> let is_async = match item.kind { ItemKind::OpaqueTy(hir::OpaqueTy { origin, .. }) => { matches!(origin, hir::OpaqueTyOrigin::AsyncFn)

Discussion:
Following the improvement for the diagnostic of the error reported in this issue , it would be nice (depending on how is prioritized) to have the same error message when instead of returning the function returns . When is returned I get a nice error message (on rustc 1.47): But if is used I get: with no suggestion to spell the type.
remove-assignment feel free to re-claim if you are working on this.
Change:
} if let Some(span) = def { <del> let explanation = "lint level defined here"; err.span_note(span, &explanation); </del> <ins> sess.diag_span_note_once(&mut err, lint, span, "lint level defined here"); </ins> } err

Discussion:
Example: Adding to a crate will point out the location of this line for every time the lint fires (). This should be listed only once. It should be reasonably easy to deduplicate these based upon equal span and message.
I think this is a good "E-easy" candidate. Relevant code is in . Using a as a field on should work, so that we only emit a note the first time we encounter it.
Question -- in , we get only "lint level defined here" per , even if it applies to multiple lints (e.g., ). Do people think it'd be better to have it like this, or would you rather see different messages for (say) and , even if they both apply to the same ?
Can someone with perms close this? I forgot to use the in .
Great! Fixed in