jiebi/CodeConvo huggingface dataset:
Change:
<ins> //@only-target-wasm32: tests WASM-specific behavior //@compile-flags: -C target-feature=-simd128 fn main() { // Calling functions with `#[target_feature]` is not unsound on WASM, see #84988 assert!(!cfg!(target_feature = "simd128")); simd128_fn(); } #[target_feature(enable = "simd128")] fn simd128_fn() {} </ins>

Discussion:
I tried this code on 1.73: Compiled it with , I expected it to compile fine as on previous 1.72.1, but it gave me these errors: It most recently worked on: 1.72.1 Output: : I read release notes for 1.73 and couldn't find anything that could be related to this, also tried to search for an existing issue about this - no luck. This issue also broke compilation of crate and transitively, Fyrox game engine.
Bisected to . cc
And then this was fixed by (or at least it started compiling since)
Hm, why does it think that the function requires that target feature? That function doesn't have any attribute... Cc
Ah, that's what changed in -- that from a bunch of functions. This was changed in Cc
That was changed in stdarch specifically in response to , to avoid breaking users who were using the already.
In principle we could probably silence this check on wasm, since we document wasm to be a target where calling functions with unsupported target features is safe.
What happens in wasm when you call a function that requires an unavailable target feature?
I am told that the wasm runtime will refuse to even load a module that contains invalid operations, so there are two options: the generated code makes no use of the target feature, and so everything just works the generated code makes use of the target feature, and we don't even ever get to the function call since loading the wasm module already failed
can you check on of the latest nightlies to verify if it works for you? (ref. )
We have a special exception for wasm that allows targetfeature functions to not be marked unsafe: We should probably have the same exception in the target-feature check in the interpreter. do you have the time for a follow-up PR implementing that?
I re-checked on latest nightly and seems to work fine:
I will do that
WG-prioritization assigning priority (). Issue is fixed on nightly+beta, leaving open to follow PR fixing label -I-prioritize +P-medium
In which version this fix will be included?
Should land in stable 1.74 (around mid November), iiuc. See or an
Change:
#![feature(alloc_system)] extern crate allocator_dylib2; <ins> // The main purpose of this test is to ensure that `alloc_system` **fails** // here (specifically the system allocator), but currently system is // disabled on quite a few platforms (bsds, emscripten, msvc, etc). To ensure // that this just passes on those platforms we link in some other allocator to // ensure we get the same error. // // So long as we CI linux/OSX we should be good. #[cfg(any(target_os = "linux", target_os = "macos"))] </ins> extern crate alloc_system; <ins> #[cfg(not(any(target_os = "linux", target_os = "macos")))] extern crate allocator1; </ins> fn main() { allocator_dylib2::foo(); }

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:
repr: Repr, } <del> #[derive(Debug)] </del> enum Repr { Os(i32), Custom(Box<Custom>),

Discussion:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::io; use std::vec; pub struct Container<'a> { reader: &'a mut Reader //~ ERROR explicit lifetime bound required } impl<'a> Container<'a> { pub fn wrap<'s>(reader: &'s mut Reader) -> Container<'s> { Container { reader: reader } } pub fn read_to(&mut self, vec: &mut [u8]) { self.reader.read(vec); } } pub fn for_stdin<'a>() -> Container<'a> { let mut r = io::stdin(); Container::wrap(&mut r as &mut Reader) } fn main() { let mut c = for_stdin(); let mut v = vec::Vec::from_elem(10, 0u8); c.read_to(v.as_mut_slice()); } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
use rustc_middle::ty::TyCtxt; use rustc_span::source_map::original_sp; <del> use rustc_span::{BytePos, Span, SyntaxContext}; </del> <ins> use rustc_span::{BytePos, Span}; </ins> use std::cmp::Ordering;

Discussion:
I tried to generate test code coverage with this source file using and the LLVM tools. Source File: I expected to see this happen: Instead, this happened: . cargo-kcov, -Zprofile+grcov, and tarpaulin agree on 76%. In the output below lines , , were not executable but should have been executable+uncovered. Line should be executable+covered. <details<summarycoverage output</summary<p</p</details:
label: +A-code-coverage cc
Thanks for the bug report ! There was a recent bug fix (PR ) that addresses most of the missing coverage in your example (except for the last one). I just tested with and I see the expected coverage now for the first three ranges you reported seeing no coverage. These three are now showing coverage (with 0 executions) as expected: I was surprised to see no coverage for line 169, and I do see the did print, so that does seem to be a bug. So as of today, this issue is still a bug that I will need to look into further:
cc: Note, here is a snippet showing the missing coverage and code relevant to its codepath. I haven't thoroughly investigated this. I should be able to reproduce this in a simplified test (without the asynctrait and executor dependencies) that I can add to our unit tests. I don't have a theory yet. It could either be the closure's MIR is not included in coverage (seems unlikely to me), or is silently dropping coverage because it doesn't like something. (This is what was happening for the other missing coverage reported in this issue, that has since been resolved.) The test (shown at the bottom) calls and awaits the implementation of below: I do see the test output, including the from above, and from the awaited call to , below: The async closure seems to be missing coverage, as shown here. Note the wrapper function is covered and called (showing the coverage of on line 168), but there should also be coverage for the awaited implicit closure (lines 168-170, I believe). Since the program output proves this is called, the coverage should be showing execution. And the test that invokes it is covered:
Thank you. I see improvement in the latest nightly.

I minified the test case to the async issues for anyone looking at this (but it still uses executor and asynctrait.) Since this function is missing coverage too the issue isn't specific to async_trait thought.
So it turns out that the internal (auto-generated) closure actually does get coverage, but for some reason the code region for the macro, by itself, is not or not counted. I've created a draft PR with a new test and current results, demonstrating this issue. Once I figure out how to fix it, I'll submit the PR with the updated results.
Update: fixes the issue.
Change:
parent_node }; <del> let module_id = if let Some(id) = base_node { </del> <ins> let mut module_id = if let Some(id) = base_node { </ins> id } else { debug!("attempting to resolve item without parent module: {}", path_str);

Discussion:
Crate exports from . is documented in quit and has no documentation in quitmacros. When that documentation has a link to , which is only in crate quit, it is unresolved. However, is resolved. Rustdoc gives no warnings with either. You can see the result with quit version 1.1.1 . cc cc
<details<summaryAll of this was wrong, I forgot to use +nightly</summaryThis isn't related to scopes, rustdoc will also fail to resolve these links: Something about the re-export itself is messing it up. </details
The good news is this is unrelated to proc-macros. Here's what I found: This is really strange. I would have expected it to resolve relative to , not relative to the current crate.
Ok, I found the issue: rustdoc and resolve disagree about which crate this is in For , rustdoc passes the original module of String, , and resolve correctly says there's no item named . But for , resolve thinks that refers to the current crate, not to alloc. This explains a lot of other broken links I've been seeing actually: anything that has will be wrong. So you were actually correct to start that this was the same issue as ;) The fix will be a little tricky ... there's no 'change ' button for resolve. There are a few things rustdoc can do: all links relative to the current module (the status quo before ). This is a no-go, because it means links will break on re-exports (). all links relative to the original module. This is what I thought was the current behavior. It means that additional documentation can't refer to things in the current lexical scope, which is non-intuitive (cc ). links in lexical scope: the original docs get resolved in the original module; the new docs get resolved in the module with the re-export. This is the ideal fix but somewhat hard to do because rustdoc doesn't distinguish between the two internally. A possible way to implement 2. is by stripping wherever we see it and resolving relative to the crate root instead of the current module. This is slightly_ hacky but should work fairly reliably.
Marking as P-high after discussing with ; it would be unfortunate to still have this bug on the first release after stabilization.
Change:
/// we would create an opaque type `type FooReturn<'a1> = impl Debug + 'a1`. /// When lowering the `Debug + 'a` bounds, we add a remapping to map `'a` to `'a1`. fn opt_local_def_id(&self, node: NodeId) -> Option<LocalDefId> { <del> self.resolver .node_id_to_def_id .get(&node) .map(|local_def_id| self.get_remapped_def_id(*local_def_id)) </del> <ins> self.orig_opt_local_def_id(node).map(|local_def_id| self.get_remapped_def_id(local_def_id)) </ins> } fn local_def_id(&self, node: NodeId) -> LocalDefId {

Discussion:
This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase. I tried this code: - I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase) Instead, this happened: It most recently worked on: 1.63 (from my repo, commit : ) It does not work anymore on version 1.64: (from my repo, commit : ) Including the backtrace by setting does not change anything to the error message. I do not know why this problem occured though. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOut of the rollup, this was probably caused by ?
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening to track backports.
can this be closed? was backported to stable, right? cc (unsure who to ping)
I have no involvement with this whatsoever.^^ is usually doing backports.
was beta backported to 1.65, which is now released. We won't be having a 1.64.1 release. So this should be considered "fixed", since it is resolved on the current stable release of Rust.
Change:
let sub_len = parts[0].snippet.trim().chars().fold(0, |acc, ch| { acc + unicode_width::UnicodeWidthChar::width(ch).unwrap_or(0) }); <del> let underline_start = span_start_pos.col.0 + start; let underline_end = span_start_pos.col.0 + start + sub_len; </del> <ins> let underline_start = span_start_pos.col_display + start; let underline_end = span_start_pos.col_display + start + sub_len; </ins> for p in underline_start..underline_end { buffer.putc(row_num, max_line_num_len + 3 + p,

Discussion:
This code (containing tabs) gives an error (): The error works fine on stable: But is mispositioned on rustc 1.25.0-nightly ( 2018-01-11) as well as on rustc 1.24.0-beta.2 ( 2018-01-10): cc
Interesting. Im new to code work so following you guys has been extremely helpful thanks
Using bisect-rust I could see that the issue started with , but probably the actual issue is somewhere else (e.g. in the machinery in that starts using for tabs).
Yeah, the issue also exists when emojis are involved (no tabs): Gives: The emoji manifestation of the issue is no beta regression, seems to exist on stable as well.
I've created for the emoji/unicode issue.
It seems to me that the issue only manifests itself in suggestions, and that is handled separately from the main diagnostics. Mentoring instructions:  needs to be modified to use instead of , the start being and the end being ( already accounts for unicode chars). This change should fix both this and .
Will pick this up
Change:
// The `liveness` variable contains the liveness of MIR locals ignoring borrows. // This is correct for movable generators since borrows cannot live across // suspension points. However for immovable generators we need to account for <del> // borrows, so we conseratively assume that all borrowed locals live forever. </del> <ins> // borrows, so we conseratively assume that all borrowed locals are live until // we find a StorageDead statement referencing the locals. </ins> // To do this we just union our `liveness` result with `borrowed_locals`, which // contains all the locals which has been borrowed before this suspension point. // If a borrow is converted to a raw reference, we must also assume that it lives

Discussion:
cc
cc
I'm hitting this a lot at the moment-- any idea what the cause might be? I'd love to help get this resolved.
I'm sometimes able to fix it by moving conditions that out of the body of an expression.
It also seems to have regressed between and -- updating the compiler caused this to happen in more places.
Possibly related to ? cc
Trying to fix in more places and it looks like it's always related to temporaries-- if I make it and then use in the place I was using it usually solves the issue.
Smaller example: ()
cc this is blocking roll out of async/await in Fuchsia
Looked at this and pointed out that it looks like typechecking thinks that isn't live at the point (which is correct) but that MIR thinks it is live (which is incorrect). I tried searching through the diff to see if there were any related PRs, but so far the only thing I've found that touches MIR is , which seems like it shouldn't be related.
Is working on bisecting this.
I think the problem is that is borrowed by and because of this the generator transformation only uses and statements to calculate liveness. However we generate a statement for before its initialiser which contains the statement. So appears live during the statement, even though its storage isn't used for anything.
Bisection pointed to as the PR that made this worse (more code ICEs now), although the minimal test case still fails before and after. cc
minimal repro: This ICE only surfaces after
using instead of makes the ICE "go away"
Ah you need at the very least to use and initializations, not . AFAIK the type of a variable could be dead at a (lifetimes not ready yet). Arguably you could also have the time before moving out and a reinitialization also count as dead, e.g. doesn't really need to keep alive.
Change:
tcx.sess, span, E0752, <del> "start is not allowed to be `async`" </del> <ins> "`start` is not allowed to be `async`" </ins> ) <del> .span_label(span, "start is not allowed to be `async`") </del> <ins> .span_label(span, "`start` is not allowed to be `async`") </ins> .emit(); error = true; } <ins> for attr in it.attrs { if attr.check_name(sym::track_caller) { tcx.sess .struct_span_err( attr.span, "`start` is not allowed to be `#[track_caller]`", ) .span_label( start_span, "`start` is not allowed to be `#[track_caller]`", ) .emit(); error = true; } } </ins> if error { return; }

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // xfail-test FIXME #11741 tuple structs ignore stability attributes #[deny(experimental)]; use std::unstable::simd; fn main() { let _ = simd::i64x2(0, 0); //~ ERROR: experimental } </ins>

Discussion:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this
Change:
}) }; let mut diff = Command::new("diff"); <del> diff.args(&["-u", "-r"]).args(&[out_dir, &compare_dir]); </del> <ins> diff.args(&["-u", "-r"]).args(&[&compare_dir, out_dir]); </ins> let output = if let Some(pager) = pager { let diff_pid = diff.stdout(Stdio::piped()).spawn().expect("failed to run `diff`");

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim
Change:
}; if s.len() == 0 { err("crate name must not be empty"); <ins> } else if s.char_at(0) == '-' { err(&format!("crate name cannot start with a hyphen: {}", s)); </ins> } for c in s.chars() { if c.is_alphanumeric() { continue } if c == '_' || c == '-' { continue } <del> err(&format!("invalid character `{}` in crate name: `{}`", c, s)[]); </del> <ins> err(&format!("invalid character `{}` in crate name: `{}`", c, s)); </ins> } match sess { Some(sess) => sess.abort_if_errors(),

Discussion:
passes the crate name to verbatim, so the leading hyphen is treated as an option. I think the best solution would be to ban leading hyphens altogether, since there's no real use case for these shenanigans.
I believe we can handle crate names starts with hyphen properly, so we don't have to ban leading hyphens.
Do you have a concrete use case for them?
no, but I'd love to make Rust to handle corner cases, as people may argue Rust don't even need to work on Windows. I made a patch to fix it but failed, I'm finding the reason, hope I can make a PR today or tomorrow.