jiebi/CodeConvo huggingface dataset:
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: cargo.rustdocflag("--extern-html-root-url"); cargo.rustdocflag("ena=https://docs.rs/ena/latest/"); <del> let mut compiler_crates = HashSet::new(); if paths.is_empty() { // Find dependencies for top level crates. for root_crate in &["rustc_driver", "rustc_codegen_llvm", "rustc_codegen_ssa"] { compiler_crates.extend( builder .in_tree_crates(root_crate, Some(target)) .into_iter() .map(|krate| krate.name), ); } </del> <ins> let root_crates = if paths.is_empty() { vec![ INTERNER.intern_str("rustc_driver"), INTERNER.intern_str("rustc_codegen_llvm"), INTERNER.intern_str("rustc_codegen_ssa"), ] </ins> } else { <del> for root_crate in paths { if !builder.src.join("compiler").join(&root_crate).exists() { builder.info(&format!( "tskipping - compiler/{} (unknown compiler crate)", root_crate )); } else { compiler_crates.extend( builder .in_tree_crates(root_crate, Some(target)) .into_iter() .map(|krate| krate.name), ); } } } </del> <ins> paths.into_iter().map(|p| builder.crate_paths[p]).collect() }; // Find dependencies for top level crates. let compiler_crates = root_crates.iter().flat_map(|krate| { builder.in_tree_crates(krate, Some(target)).into_iter().map(|krate| krate.name) }); </ins> let mut to_open = None; <del> for krate in &compiler_crates { </del> <ins> for krate in compiler_crates { </ins> // Create all crate output directories first to make sure rustdoc uses // relative links. // FIXME: Cargo should probably do this itself.
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: ar: HashMap<TargetSelection, PathBuf>, ranlib: HashMap<TargetSelection, PathBuf>, // Miscellaneous <ins> // allow bidirectional lookups: both name -> path and path -> name </ins> crates: HashMap<Interned<String>, Crate>, <ins> crate_paths: HashMap<PathBuf, Interned<String>>, </ins> is_sudo: bool, ci_env: CiEnv, delayed_failures: RefCell<Vec<String>>,
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: ar: HashMap::new(), ranlib: HashMap::new(), crates: HashMap::new(), <ins> crate_paths: HashMap::new(), </ins> is_sudo, ci_env: CiEnv::current(), delayed_failures: RefCell::new(Vec::new()),
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: .filter(|dep| dep.source.is_none()) .map(|dep| INTERNER.intern_string(dep.name)) .collect(); <del> build.crates.insert(name, Crate { name, deps, path }); </del> <ins> let krate = Crate { name, deps, path }; let relative_path = krate.local_path(build); build.crates.insert(name, krate); let existing_path = build.crate_paths.insert(relative_path, name); assert!(existing_path.is_none(), "multiple crates with the same path"); </ins> } } }
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: use crate::tool::{self, SourceType, Tool}; use crate::toolstate::ToolState; use crate::util::{self, add_link_lib_path, dylib_path, dylib_path_var, output, t}; <del> use crate::Crate as CargoCrate; </del> use crate::{envify, CLang, DocTests, GitRepo, Mode}; const ADB_TEST_DIR: &str = "/data/tmp/work";
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: fn make_run(run: RunConfig<'_>) { let builder = run.builder; let compiler = builder.compiler(builder.top_stage, run.build_triple()); <ins> let krate = builder.crate_paths[&run.path]; let test_kind = builder.kind.into(); </ins> <del> for krate in builder.in_tree_crates("rustc-main", Some(run.target)) { if krate.path.ends_with(&run.path) { let test_kind = builder.kind.into(); builder.ensure(CrateLibrustc { compiler, target: run.target, test_kind, krate: krate.name, }); } } </del> <ins> builder.ensure(CrateLibrustc { compiler, target: run.target, test_kind, krate }); </ins> } fn run(self, builder: &Builder<'_>) {
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: fn make_run(run: RunConfig<'_>) { let builder = run.builder; let compiler = builder.compiler(builder.top_stage, run.build_triple()); <ins> let test_kind = builder.kind.into(); let krate = builder.crate_paths[&run.path]; </ins> <del> let make = |mode: Mode, krate: &CargoCrate| { let test_kind = builder.kind.into(); builder.ensure(Crate { compiler, target: run.target, mode, test_kind, krate: krate.name, }); }; for krate in builder.in_tree_crates("test", Some(run.target)) { if krate.path.ends_with(&run.path) { make(Mode::Std, krate); } } </del> <ins> builder.ensure(Crate { compiler, target: run.target, mode: Mode::Std, test_kind, krate }); </ins> } /// Runs all unit tests plus documentation tests for a given crate defined
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim

Related discussion:
text: // so add an empty section. if file.format() == object::BinaryFormat::Coff { file.add_section(Vec::new(), ".text".into(), object::SectionKind::Text); <ins> // We handle the name decoration of COFF targets in `symbol_export.rs`, so disable the // default mangler in `object` crate. file.set_mangling(object::write::Mangling::None); </ins> } for (sym, kind) in symbols.iter() {
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim

Related discussion:
text: for_each_exported_symbols_include_dep(tcx, crate_type, |symbol, info, cnum| { if info.level.is_below_threshold(export_threshold) || info.used { symbols.push(( <del> symbol_export::symbol_name_for_instance_in_crate(tcx, symbol, cnum), </del> <ins> symbol_export::linking_symbol_name_for_instance_in_crate(tcx, symbol, cnum), </ins> info.kind, )); }
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim

Related discussion:
text: use rustc_middle::ty::query::{ExternProviders, Providers}; use rustc_middle::ty::subst::{GenericArgKind, SubstsRef}; use rustc_middle::ty::Instance; <del> use rustc_middle::ty::{SymbolName, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, SymbolName, TyCtxt}; </ins> use rustc_session::config::CrateType; use rustc_target::spec::SanitizerSet;
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim

Related discussion:
text: #![feature(nll)] #![feature(associated_type_bounds)] #![feature(strict_provenance)] <ins> #![feature(int_roundings)] </ins> #![recursion_limit = "256"] #![allow(rustc::potential_query_instability)]
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim

Related discussion:
text: <ins> // build-pass // only-x86-windows #![crate_type = "cdylib"] #![feature(abi_vectorcall)] #[no_mangle] extern "stdcall" fn foo(_: bool) {} #[no_mangle] extern "fastcall" fn bar(_: u8) {} #[no_mangle] extern "vectorcall" fn baz(_: u16) {} </ins>
Code change:
IIRC there is a broken link checker, but somehow it doesn't catch this case: ! which is a 404 modify labels: A-docs
Also, all source links of the macros in are broken as well.
Another reexport bug. :) EDIT: so in here the problem is that the crate isn't documented on It should redirect to .
I think the right fix is to pass -Zrustdoc-map to cargo when documenting the standard library. We already do that for the compiler docs: mentoring instructions: add that same flag to .
cc , which is one way to fix this in rustdoc, but will result in a worse experience for the source view.
I just opened a PR for this issue: I confirmed that it fixes this issue. One of my concerns is that it is very similar to even if I followed the mentoring instructions. And the other concern is that although this PR fixes the main issue, there is another issue: Macros here seems still not working: Actually is working after this PR but others aren't; I think there is some mismatch about generating links between Cargo and I can investigate this second issue further in this issue or in a new issue but at first I wanna ensure that I am on the right way.

Related discussion:
text: .arg("--target-dir") .arg(&*target_dir.to_string_lossy()) .arg("-Zskip-rustdoc-fingerprint") <ins> .arg("-Zrustdoc-map") .rustdocflag("--extern-html-root-url") .rustdocflag("std_detect=https://docs.rs/std_detect/latest/") .rustdocflag("--extern-html-root-takes-precedence") </ins> .rustdocflag("--resource-suffix") .rustdocflag(&builder.version); for arg in extra_args {
Code change:
Current docs on derive : I interpret the above statement as " compares enum discriminants", which is not the case. This is true for enums variants with no data, however for enum variants that are struct-like or tuple struct-like, derived actually compares the fields (which is expected) and not just discriminants: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +A-docs +C-cleanup +E-easy +T-libs-api
claim

Related discussion:
text: /// /// This trait can be used with `#[derive]`. When `derive`d on structs, two /// instances are equal if all fields are equal, and not equal if any fields <del> /// are not equal. When `derive`d on enums, each variant is equal to itself /// and not equal to the other variants. </del> <ins> /// are not equal. When `derive`d on enums, two instances are equal if they /// are the same variant and all fields are equal. </ins> /// /// ## How can I implement `PartialEq`? ///
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: use crate::ffi::{CStr, CString}; use crate::fmt; use crate::io; <ins> use crate::marker::PhantomData; </ins> use crate::mem; use crate::num::NonZeroU64; use crate::num::NonZeroUsize;
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: unsafe fn spawn_unchecked_<'a, 'scope, F, T>( self, f: F, <del> scope_data: Option<&'scope scoped::ScopeData>, </del> <ins> scope_data: Option<Arc<scoped::ScopeData>>, </ins> ) -> io::Result<JoinInner<'scope, T>> where F: FnOnce() -> T,
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: })); let their_thread = my_thread.clone(); <del> let my_packet: Arc<Packet<'scope, T>> = Arc::new(Packet { scope: scope_data, result: UnsafeCell::new(None) }); </del> <ins> let my_packet: Arc<Packet<'scope, T>> = Arc::new(Packet { scope: scope_data, result: UnsafeCell::new(None), _marker: PhantomData, }); </ins> let their_packet = my_packet.clone(); let output_capture = crate::io::set_output_capture(None);
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: unsafe { *their_packet.result.get() = Some(try_result) }; }; <del> if let Some(scope_data) = scope_data { </del> <ins> if let Some(scope_data) = &my_packet.scope { </ins> scope_data.increment_num_running_threads(); }
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: // An Arc to the packet is stored into a `JoinInner` which in turns is placed // in `JoinHandle`. struct Packet<'scope, T> { <del> scope: Option<&'scope scoped::ScopeData>, </del> <ins> scope: Option<Arc<scoped::ScopeData>>, </ins> result: UnsafeCell<Option<Result<T>>>, <ins> _marker: PhantomData<Option<&'scope scoped::ScopeData>>, </ins> } // Due to the usage of `UnsafeCell` we need to manually implement Sync.