jiebi/CodeConvo huggingface dataset:
Code change:
// components like the llvm tools and LLD. LLD is included below and // tools/LLDB come later, so let's just throw it in the rustc // component for now. <del> maybe_install_llvm_dylib(builder, host, image); </del> <ins> maybe_install_llvm_runtime(builder, host, image); </ins> // Copy over lld if it's there if builder.config.lld_enabled {

Related discussion:
text: Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?
Code change:
<del> error: `impl Trait` can only mention lifetimes bound at the fn or impl level </del> <ins> error: `impl Trait` can only mention lifetimes from an fn or impl </ins> --> $DIR/universal_wrong_hrtb.rs:5:73 | LL | fn test_argument_position(x: impl for<'a> Trait<'a, Assoc = impl Copy + 'a>) {} <del> |                                                                         ^^ | note: lifetime declared here --> $DIR/universal_wrong_hrtb.rs:5:39 | LL | fn test_argument_position(x: impl for<'a> Trait<'a, Assoc = impl Copy + 'a>) {} |                                       ^^ </del> <ins> |                                       -- lifetime declared here         ^^ </ins> error: aborting due to previous error

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
minimized
Bisected to :sweatsmile:
Code change:
echo '{"ipv6":true,"fixed-cidr-v6":"fd9a:8454:6789:13f7::/64"}' | sudo tee /etc/docker/daemon.json sudo service docker restart displayName: Enable IPv6 <del> condition: and(succeeded(), eq(variables['Agent.OS'], 'Linux')) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), eq(variables['Agent.OS'], 'Linux')) </ins> # Check out all our submodules, but more quickly than using git by using one of # our custom scripts

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
cx: &MatchCheckCtxt<'p, 'tcx>, column: &[&DeconstructedPat<'p, 'tcx>], ) -> Vec<WitnessPat<'tcx>> { <ins> if column.is_empty() { return Vec::new(); } </ins> let ty = column[0].ty(); let pcx = &PatCtxt { cx, ty, span: DUMMY_SP, is_top_level: false };

Related discussion:
text: File: auto-reduced (treereduce-rust): original: 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
What is intriguing is that the transmute doesn't fail, as it is a transmute from a 1ZST to a Never-like type, which has no representations. This code is definitely unsound, but I guess this is already a known thing.
Regression in cc
:facepalm: Oops, fix here: Good catch!
Code change:
// We use the *previous* span because if the type is known *here* it means // it was *evaluated earlier*. We don't do this for method calls because we // evaluate the method's self type eagerly, but not in any other case. <del> err.span_label( span, with_forced_trimmed_paths!(format!( "here the type of `{ident}` is inferred to be `{ty}`", )), ); </del> <ins> if !span.overlaps(mismatch_span) { err.span_label( span, with_forced_trimmed_paths!(format!( "here the type of `{ident}` is inferred to be `{ty}`", )), ); } </ins> break; } prev = ty;

Related discussion:
text: I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble
Code change:
} 0 => {} _ => { <del> // linux returns POLLOUT|POLLERR|POLLHUP for refused connections (!), so look // for POLLHUP rather than read readiness if pollfd.revents & libc::POLLHUP != 0 { let e = self.take_error()?.unwrap_or_else(|| { io::const_io_error!( io::ErrorKind::Uncategorized, "no error set after POLLHUP", ) }); return Err(e); </del> <ins> if cfg!(target_os = "vxworks") { // VxWorks poll does not return  POLLHUP or POLLERR in revents. Check if the // connnection actually succeeded and return ok only when the socket is // ready and no errors were found. if let Some(e) = self.take_error()? { return Err(e); } } else { // linux returns POLLOUT|POLLERR|POLLHUP for refused connections (!), so look // for POLLHUP or POLLERR rather than read readiness if pollfd.revents & (libc::POLLHUP | libc::POLLERR) != 0 { let e = self.take_error()?.unwrap_or_else(|| { io::const_io_error!( io::ErrorKind::Uncategorized, "no error set after POLLHUP", ) }); return Err(e); } </ins> } return Ok(());

Related discussion:
text: I'm tracking a issue with connecttimeout function on rust for vxworks. The function is also accepting connections on a non responsive server port. I get errors on unreachable host, but with host that are reachable any connection to a non existent server port is not resulting in an error. example program: Results: #./exe 127.0.0.1:90 /// No server at this port Successfully connected to server #./exe 192.0.0.1:20 //// Host is unreachable so correct behaviour. Failed to connect to server #./exe 172.16.2.223:8002 //Host is reachable, but there's no server at this port Successfully connected to server This is not observed with the connect function. I don't see a specified folder in library/std/src/sys/pal for vxworks. I found only one file for vxworks files. Does vxworks fall back on unix implementations for these functionalities? Any leads on how to proceed would be really helpful.
I don't mean to quibble much but tracking issues are not for "tracking" bugs, they are for tracking long-term projects that need issues-that-connect-issues.
Yes, see for why: basically our support was previously a trivial copy of the Unix support. The result may be buggy, because we do not really run CI against VxWorks. We are happy to accept patches, and even happier to have maintainers who are interested in repairing the target on a regular basis.
Thank You. I'll be continuously working on vxworks rust. So I'll be able to check this on a regular basis. Since rust 1.6 we've been maintaining a custom patch for rust build for vxworks. I'll update it for nightly and create a PR. I would like to be a code maintainer for this.
All you have to do to be listed as a maintainer is to add a doc using this template in rustc/src/platform-support/
Code change:
impl<'tcx> MirPass<'tcx> for SimplifyArmIdentity { fn run_pass(&self, _: TyCtxt<'tcx>, _: MirSource<'tcx>, body: &mut Body<'tcx>) { <del> for bb in body.basic_blocks_mut() { </del> <ins> let (basic_blocks, local_decls) = body.basic_blocks_and_local_decls_mut(); for bb in basic_blocks { </ins> // Need 3 statements: let (s0, s1, s2) = match &mut *bb.statements { [s0, s1, s2] => (s0, s1, s2),

Related discussion:
text: PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are
Code change:
impl<'tcx> MirPass<'tcx> for SimplifyArmIdentity { fn run_pass(&self, _: TyCtxt<'tcx>, _: MirSource<'tcx>, body: &mut Body<'tcx>) { <del> for bb in body.basic_blocks_mut() { </del> <ins> let (basic_blocks, local_decls) = body.basic_blocks_and_local_decls_mut(); for bb in basic_blocks { </ins> // Need 3 statements: let (s0, s1, s2) = match &mut *bb.statements { [s0, s1, s2] => (s0, s1, s2),

Related discussion:
text: Since few Rustc nightly versions I see a miscompilation problem with the code below. I am using: If I compile with: The code:
NB: this is because it needs an unstable CLI flag to reproduce.
cc since this might have something to do with recent const-eval work (apologies if I left anyone out)
I've managed to minify it to
Bisected it to , most probably the same issue as
Code change:
loop { let tree = iter.stack.pop().or_else(|| { let next = iter.cursor.next_with_joint()?; <del> let lookahead = iter.cursor.look_ahead(0); Some(TokenTree::from_internal((next, lookahead, self.sess, &mut iter.stack))) </del> <ins> Some(TokenTree::from_internal((next, self.sess, &mut iter.stack))) </ins> })?; // A hack used to pass AST fragments to attribute and derive macros // as a single nonterminal token instead of a token stream.

Related discussion:
text: Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the
Code change:
#[license = "MIT/ASL2"]; #[crate_type = "rlib"]; #[crate_type = "dylib"]; <del> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk.png", </del> <ins> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", </ins> html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")];

Related discussion:
text: It's currently very bright and distracting (IMO). (Sorry :( ) Current scheme, for future triage/comparison purposes: !
I think I should reconsider my career in graphic design.
I'm looking at this.
(The relevant file is , if you're lost. :) )
BTW I was wondering, why not just use for src line numbering? Probably more optimized/idiomatic in the browser.
Also, it's pretty much impossible to have consistency between rustdoc and the old codemirror (tutorial) since both parsers behave very differently. would it be possible to pass the standalone documentation through rustdoc?
Doesn't this mean every line is a new tag? Also, it possibly screws with copy-paste and making the formatting consistent. This bug is specifically about the colour scheme of rustdoc since it's so wild. Also, about using rustdoc for everything.
My preference for the highlighting scheme is bold for keywords, green for macros, red for strings (the current color is fine), gray for comments (would be nice if code within comments were highlighted). I'd also like to hear more suggestions before we change it.
Something I hacked up a few days ago: ! (The macro colour wasn't "optimised" at all.)
No, it would look like this: I think it would be better to use that since that's the browser native numberings. No it doesn't. The identifier of a list aren't inlined with the content. is an example.
Oh, awesome. It does seem like a good idea, if you can get that to work.
Another note: current rustdoc parsing could be improved, i.e. the "ident" class corresponds to variable names, function names, paths, parameters... could be more split if you ask me.
The highlighting is performed by just by the token types the lexer (with a little bit of extra logic for attributes, macros and $ non-terminals in macros) and so does not have that information.
Code change:
optopt("", "host", "the host to build for", "HOST"), optopt("", "gdb-version", "the version of GDB used", "VERSION STRING"), optopt("", "lldb-version", "the version of LLDB used", "VERSION STRING"), <ins> optopt("", "llvm-version", "the version of LLVM used", "VERSION STRING"), </ins> optopt("", "android-cross-path", "Android NDK standalone path", "PATH"), optopt("", "adb-path", "path to the android debugger", "PATH"), optopt("", "adb-test-dir", "path to tests for the android debugger", "PATH"),

Related discussion:
text: I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!
Code change:
'{' => { let curr_last_brace = self.last_opening_brace; let byte_pos = self.to_span_index(pos); <del> let lbrace_end = InnerOffset(byte_pos.0 + 1); </del> <ins> let lbrace_end = self.to_span_index(pos + 1); </ins> self.last_opening_brace = Some(byte_pos.to(lbrace_end)); self.cur.next(); if self.consume('{') {

Related discussion:
text: I tried this code: I expected to see this happen: a "no value found" error pointing at the token Instead, this happened: a "no value found" error pointing at the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This doesn't seem to be an issue on stable, interestingly.
Yep, it works fine on 1.63.0, but has the problem on 1.65.0-beta.1 and the latest nightly.
claim
Code change:
} #[stable(feature = "rust1", since = "1.0.0")] <del> impl Read for File { </del> <ins> impl Read for &File { </ins> fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { self.inner.read(buf) }

Related discussion:
text: Some types ( and in particular) implement and on . If one of these types are wrapped in an (or ), there is no real reason why one shouldn't be able to call or methods on it. For example, this code should compile: I think this can be implemented pretty straightforwardly by adding the following impls to and : Are there good reasons for why impls like these shouldn't be ?
Closing because generic impls like proposed won't behave correctly, as described in .
Code change:
<ins> //@ run-rustfix // Check the `unused_parens` suggestion for paren_expr with attributes. // The suggestion should retain attributes in the front. #![feature(stmt_expr_attributes)] #![deny(unused_parens)] pub fn foo() -> impl Fn() { let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); //~ERROR unnecessary parentheses (#[inline] #[allow(dead_code)] || println!("Hello!")) //~ERROR unnecessary parentheses } fn main() { let _ = foo(); } </ins>

Related discussion:
text: <!-- 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: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Code change:
lt_op: |_| self.tcx.lifetimes.re_erased, ct_op: |c| c, ty_op: |t| match *t.kind() { <del> ty::Infer(ty::TyVar(vid)) => self.tcx.mk_ty_infer(ty::TyVar(self.root_var(vid))), </del> <ins> ty::Infer(ty::TyVar(_)) => self.tcx.mk_ty_var(ty::TyVid::from_u32(0)), </ins> ty::Infer(ty::IntVar(_)) => { self.tcx.mk_ty_infer(ty::IntVar(ty::IntVid { index: 0 })) }

Related discussion:
text: I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble
Code change:
fn report(&mut self, error: GroupedMoveError<'tcx>) { let (mut err, err_span) = { <del> let (span, original_path, kind): (Span, &Place<'tcx>, &IllegalMoveOriginKind<'_>) = </del> <ins> let (span, use_spans, original_path, kind,): ( Span, Option<UseSpans>, &Place<'tcx>, &IllegalMoveOriginKind<'_>, ) = </ins> match error { GroupedMoveError::MovesFromPlace { span, ref original_path, ref kind, .. } | GroupedMoveError::MovesFromValue { span, ref original_path, ref kind, .. } => { <del> (span, original_path, kind) </del> <ins> (span, None, original_path, kind) </ins> } GroupedMoveError::OtherIllegalMove { use_spans, ref original_path, ref kind } => { <del> (use_spans.args_or_use(), original_path, kind) </del> <ins> (use_spans.args_or_use(), Some(use_spans), original_path, kind) </ins> }, }; debug!("report: original_path={:?} span={:?}, kind={:?} 

Related discussion:
text: gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler
Code change:
0, ); if result != stackaddr || result == MAP_FAILED { <del> panic!("failed to allocate a guard page"); </del> <ins> panic!("failed to allocate a guard page: {}", io::Error::last_os_error()); </ins> } let result = mprotect(stackaddr, page_size, PROT_NONE); if result != 0 { <del> panic!("failed to protect the guard page"); </del> <ins> panic!("failed to protect the guard page: {}", io::Error::last_os_error()); </ins> } let guardaddr = stackaddr as usize;

Related discussion:
text: There is too little confidence in this mistake, why not return to errno. The mmap interface provides the errno, such as the ENOMEM and SIGSEGV interfaces. panic!("failed to allocate an alternative stack")
!
Please try again your code latest nightly Rust version. Also could you paste the ICE backtrace? label E-needs-mcve I-ICE
This is not a ICE This issue propose printing errno on this :
Probably we want this then: label: -I-ICE, -T-compiler, +T-libs