jiebi/CodeConvo huggingface dataset:
Change:
.arg("--disable-ldconfig"); build.run(&mut cmd); } <ins> fn add_destdir(path: &Path, destdir: &Option<PathBuf>) -> PathBuf { let mut ret = match *destdir { Some(ref dest) => dest.clone(), None => return path.to_path_buf(), }; for part in path.components() { match part { Component::Normal(s) => ret.push(s), _ => {} } } return ret } </ins>

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
Change:
_ => false, }) => { <del> Some(parent_def_id.to_def_id()) </del> <ins> Some(parent_did) </ins> } _ => None, }

Discussion:
<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(effects) -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [adtdestructor] computing impl for [checkwellformed] checking that is well-formed -- label +F-constmutrefs +F-consttrait_impl +F-effects
Regression in of
doesn't require any features actually, rip
Removed irrelevant errors:
Minimized: or
Change:
use rustc_span::{Span, Symbol}; use thin_vec::{ThinVec, thin_vec}; <ins> use crate::errors; </ins> macro_rules! path { ($span:expr, $($part:ident)::*) => { vec![$(Ident::new(sym::$part, $span),)*] } }

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.
Change:
mir::Rvalue::Repeat(ref elem, ref count) => { let elem = self.trans_operand(bcx, elem); <del> let size = self.trans_constant(bcx, count).immediate(); </del> <ins> let size = self.trans_constval(bcx, &count.value, count.ty).immediate(); </ins> let base = expr::get_dataptr(bcx, dest.llval); tvec::iter_vec_raw(bcx, base, elem.ty, size, |bcx, llslot, _| { self.store_operand(bcx, llslot, elem);

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> #![feature(type_alias_impl_trait)] pub type Opaque<'a> = impl Sized; fn get_one<'a>(a: *mut &'a str) -> impl IntoIterator<Item = Opaque<'a>> { if a.is_null() { Some(a) } else { None::<Opaque<'static>> //~^ ERROR hidden type for `Opaque<'static>` captures lifetime that does not appear in bounds } } fn main() {} </ins>

Discussion:
The following should not compile. Adapted from . This is a quick issue, I did not have the chance to look into it deeper but I guess it affects ATPIT as well. cc
This used to be an error in , but then incorrectly accepted in .
Change:
#[empty_helper] //~ ERROR `empty_helper` is ambiguous #[derive(Empty)] struct S { <del> #[empty_helper] //~ ERROR `empty_helper` is ambiguous </del> <ins> #[empty_helper] // OK, no ambiguity, derive helpers have highest priority </ins> field: [u8; { use empty_helper; //~ ERROR `empty_helper` is ambiguous <del> #[empty_helper] //~ ERROR `empty_helper` is ambiguous </del> <ins> #[empty_helper] // OK, no ambiguity, derive helpers have highest priority </ins> struct U; mod inner {

Discussion:
So pointed out to me that some recent changes in name resolution seem to have broken . They pointed me at dealing with the fallout -- maybe you can leave a few notes as to what errors you were seeing before this commit? cc -- could this be the recent changes around name resolution of helper attributes in macros? It seems the relevant code is stuff like:
(Nominated for discussion around the breakage policy/implications here.)
Duplicate of , I'll prepare a fix.
fix Or rather a "tiebreaker" for the ambiguity, since both names are indeed in scope and create ambiguity, which is correctly detected after .
Fixed in

This is a dependency of . I was trying to compile ; it failed on both the master branch and the current published version. is ambiguous (derive helper attribute vs any other name) Indeed, the code does seem to treat as simultaneously a derive macro and an attribute macro. It works fine on stable.
Example of failing builds:
modify labels: +E-needs-bisection It'd be nice if somebody pinpointed specific PR (or nightly at least). Maybe has a clue what could have caused it.
Seems to be introduced at nightly-2019-11-17. Unfortunately I'm not able to bisect that further because cargo-bisect-rustc is telling me:
Likely
This is a consequence of , I'll provide a ASAP.
Fixed in
Change:
// We cache the result of `Fields::wildcards` because it is used a lot. let spec_matrix = start_matrix.specialize_constructor(pcx, &ctor); let v = v.pop_head_constructor(cx, &ctor); <del> let usefulness = is_useful(cx, &spec_matrix, &v, witness_preference, hir_id, is_under_guard, false); </del> <ins> let usefulness = ensure_sufficient_stack(|| { is_useful(cx, &spec_matrix, &v, witness_preference, hir_id, is_under_guard, false) }); </ins> let usefulness = usefulness.apply_constructor(pcx, start_matrix, &ctor); // When all the conditions are met we have a match with a `non_exhaustive` enum

Discussion:
The following macro generates a function with 4096 entries in the tuple. () It’s explicitly a stack overflow on stable and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety. label I-crash, T-compiler
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Digged a bit, this is indeed a stack overflow. Since rustc uses stacker, if we moved to a segemented stack instead of the native stack, std didn't know this is a stack overflow and so it appears as segfault instead. The root cause is that uses recursion.
Change:
fn test_escape() { assert_eq!(pns("has no escapes"), None); assert_eq!(pns("has no escapes, either %"), None); <del> assert_eq!(pns("*so* has a %% escape"), Some((S::Escape, " escape"))); assert_eq!(pns("%% leading escape"), Some((S::Escape, " leading escape"))); assert_eq!(pns("trailing escape %%"), Some((S::Escape, ""))); </del> <ins> assert_eq!(pns("*so* has a %% escape"), Some((S::Escape((11, 13)), " escape"))); assert_eq!(pns("%% leading escape"), Some((S::Escape((0, 2)), " leading escape"))); assert_eq!(pns("trailing escape %%"), Some((S::Escape((16, 18)), ""))); </ins> } #[test]

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2021-01-01 to nightly-2021-12-24 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
The regression happened in . cc
label regression-from-stable-to-stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I've been taking a look at this. It's pretty interesting. I'm not entirely sure I'll be able to work it out, but I figure I may as well assign myself for the time being while I attempt to solve it.
Another test case:
The problem seems to reside within the crate , in the files and . The function in has a macro, , which is in charge of looking for foreign substitutions - that is, someone using printf or shell style formatting rather than Rust's style. It's a macro so it can be generic over the two types of substitution. The first time this macro is called, for printf substitutions, it finds two (I think "%%" and "%", though I'm not sure it's exactly that). The code that actually detects the substitutions is in . When parsing the substitution, in the function , it is somehow finding that the second substitution has a boundary in the middle of the character. I'm not sure exactly how yet. This gets turned into a span in . The span is malformed, as it splits a character in two, so the second the code tries to use it for anything it trips an assertion and causes this ICE. The remaining problem is figuring out what's going wrong in . This sort of string manipulation is not my forte. I'll probably take another few cracks at it though.
Something is broken about . This change makes the ICE go away (but probably breaks other things):
When returns here: it seems like we should increment by , but we actually only increment it by 2:
yes, I get the exact same error. . The error disappears if you add a new line after the , so maybe your text editor did that automatically.

That was it, thanks. I'm going to unassign myself from this. I do hope my exploration ends up being helpful to whoever fixes it though. if you want to fix this yourself, you certainly seem further along than I was, though you shouldn't feel any pressure to do so if you don't want to.
I put up a PR for a
I opened a new issue for your bug, because it's not exactly the same as this one.
Change:
| Node::ImplItem(&hir::ImplItem { kind: hir::ImplItemKind::Fn(..), .. }) => { let def_id = tcx.hir().local_def_id(hir_id); let generics = tcx.generics_of(def_id); <del> if !generics.requires_monomorphization(tcx) && // Functions marked with #[inline] are only ever codegened // with "internal" linkage and are never exported. !Instance::mono(tcx, def_id.to_def_id()).def.generates_cgu_internal_copy(tcx) </del> <ins> if !generics.requires_monomorphization(tcx) // Functions marked with #[inline] are codegened with "internal" // linkage and are not exported unless marked with an extern // inidicator && (!Instance::mono(tcx, def_id.to_def_id()).def.generates_cgu_internal_copy(tcx) || tcx.codegen_fn_attrs(def_id.to_def_id()).contains_extern_indicator()) </ins> { Some(def_id) } else {

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
let handle = UvHandle::alloc(None::<TtyWatcher>, uvll::UV_TTY); let mut watcher = TtyWatcher { tty: handle, <del> stream: StreamWatcher::new(handle), </del> <ins> stream: StreamWatcher::new(handle, true), </ins> home: io.make_handle(), fd: fd, };

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
.and_then(|needed_cap| needed_cap.checked_next_power_of_two()) .expect("capacity overflow"); <del> if new_cap > self.capacity() { </del> <ins> if new_cap > old_cap { </ins> self.buf.reserve_exact(used_cap, new_cap - used_cap); unsafe { self.handle_cap_increase(old_cap);

Discussion:
I've been seeing lots of bad behavior trying to use VecDeque. I've boiled it down to a relatively simple example which shows some of the bad behavior I was seeing and additionally seg faults. This was with: rustc 1.20.0 ( 2017-08-27) binary: rustc commit-hash: commit-date: 2017-08-27 host: x86_64-apple-darwin release: 1.20.0 LLVM version: 4.0 and also rust 1.19 The output I expect to see is: The output I get is: Note that the fourth from the last byte should be D9. Work around seems to be to use a large VecDeqeue capacity. Here's the code:
Valgrind output with the allocator switched over to alloc_system:
Here is what I believe is a minimal reproduction: Valgrind:
It looks like this was introduced two years ago in Specifically, mixes up its "raw" capacity and the user-visible capacity. These differ by one, so reserve can end up in a situation where it calls into without the capacity having actually increased. The implementation of that method assumes this doesn't happen, and as a result messes up the head and tail pointers so that the next push writes off the end of the buffer. Making a fix right now.
This bug is referenced in :
Change:
f(self); if let Some(els) = els { // borrowing because we need to test the discriminant <del> self.maybe_read_scrutinee(expr, expr_place.clone(), from_ref(pat).iter()); </del> <ins> return_if_err!(self.maybe_read_scrutinee( expr, expr_place.clone(), from_ref(pat).iter() )); </ins> self.walk_block(els) } self.walk_irrefutable_pat(&expr_place, &pat);

Discussion:
<details</summary</details<!-- 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. --:
I will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
<ins> // edition:2018 // // Regression test for issue #75785 // Tests that we don't point to a confusing named // region when emitting a diagnostic pub async fn async_fn(x: &mut i32) -> (&i32, &i32) { let y = &*x; *x += 1; //~ ERROR cannot assign to (&32, y) } fn main() {} </ins>

Discussion:
Output (): The lifetime name should be given to the second reference in the tuple. modify labels: C-bug A-async-await A-diagnostics A-lifetimes T-compiler
On stable the output is different: Per bisect-rustc, the commit that changed the output is - almost definitely . is there something that can be done to improve this case? <details<summaryBisect output</summarysearched nightlies: from nightly-2020-06-01 to nightly-2020-07-15 regressed nightly: nightly-2020-07-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Here's the output with removed: It looks like we're missing the "let's call the lifetime of this reference" note in the case.
The current equivalent of that annotation is the note at the bottom: (see ) I actually ran into this while testing a potential fix for that issue - it would make the output Which still points at the wrong reference.
Are you still planning to work on this?
Change:
| LL |     let _: ::u8; |              ^^ not found in the crate root <ins> | help: possible candidate is found in another module, you can import it into scope | LL | use std::primitive::u8; | </ins> error[E0061]: this function takes 0 parameters but 1 parameter was supplied --> $DIR/resolve-primitive-fallback.rs:3:5

Discussion:
I got a bug report on Diesel from someone who has a database column called . This lead to us attempting to generate the following code: which causes a type mismatch because their struct is shadowing the primitive. I'd like to change the generated code to be , which is the path that the rustdoc for libstd indicates it should be, but the type doesn't exist there, or anywhere else I can find. I would assume the same issue exists for , , and all the numeric types.
Since the module already exists, the type cannot be called . But it can be aliased as I guess.
would make sense as well
Related: The reason these primitives are not put into prelude was because but I think this is no longer a problem? (cc
Tagging this as a library issue. The solution (if it happens on our side) is to add a module or (and reexport it from as well) as described in In the meantime Diesel can privately define such a module itself and use it when unintended shadowing can happen. It doesn't make much sense to put primitive types into the std prelude because they are already in a prelude actually, it's just not the std prelude, but an additional language prelude one level below (as it was decided in and ).
I agree that primitives should be exposed at some absolute path. sounds reasonable.
I'd be happy to work on this. What's needed besides the implementation? I'm not entirely sure what a test for this should look like. Just a run-pass test that shadows and references ? Do we need one for every type?
I would start with a PR that has: Implementation, Module-level documentation for std::primitive with a helpful example that communicates why you may want to use this, One run-pass test for a shadowed bool as you suggested.
Sounds good. I'll try to get that PR done this week.
Does this need a feature gate?
Yes I believe so.
Triage: not aware of anything happening here.
Change:
fn repr(&self) -> T { unsafe { mem::transmute_copy(&self) } } } <del> impl<T> Repr<Slice<T>> for [T] {} impl Repr<Slice<u8>> for str {} </del> <ins> unsafe impl<T> Repr<Slice<T>> for [T] {} unsafe impl Repr<Slice<u8>> for str {} </ins>

Discussion:
Here's the definition Implementing is done like so: A safe implementation invokes a transmute between arbitrary types. Perhaps is more appropriately an unsafe trait?
Agreed. Unsafe trait is the way to go.
Change:
cmd.arg("--channel").arg(&builder.config.channel); <ins> if !builder.config.omit_git_hash { cmd.arg("--git-hash"); } </ins> if let Some(commit) = builder.config.download_rustc_commit() { cmd.env("FAKE_DOWNLOAD_RUSTC_PREFIX", format!("/rustc/{commit}")); }

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim