jiebi/CodeConvo huggingface dataset:
Change:
/// # Examples /// /// ``` <del> /// #![feature(arc_mutate_strong_count)] /// </del> /// use std::sync::Arc; /// /// let five = Arc::new(5); /// /// unsafe { ///     let ptr = Arc::into_raw(five); <del> ///     Arc::incr_strong_count(ptr); </del> <ins> ///     Arc::increment_strong_count(ptr); </ins> /// ///     // Those assertions are deterministic because we haven't shared ///     // the `Arc` between threads. ///     let five = Arc::from_raw(ptr); ///     assert_eq!(2, Arc::strong_count(&five)); <del> ///     Arc::decr_strong_count(ptr); </del> <ins> ///     Arc::decrement_strong_count(ptr); </ins> ///     assert_eq!(1, Arc::strong_count(&five)); /// } /// ``` #[inline] <del> #[unstable(feature = "arc_mutate_strong_count", issue = "71983")] pub unsafe fn decr_strong_count(ptr: *const T) { </del> <ins> #[stable(feature = "arc_mutate_strong_count", since = "1.51.0")] pub unsafe fn decrement_strong_count(ptr: *const T) { </ins> unsafe { mem::drop(Arc::from_raw(ptr)) }; }

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- [ ] Can we improve the docs phrasing on ? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial PR in Stabilization PR in
Hello Would it make sense to also include similar methods for Rc? And possibly similar ones to both Weaks? It would be in part for the sake of completeness, but I do some manipulation like this in the arc-swap crate and if this would become the „official“ way, it would be nice to be supported on all the related types.
I think that's a great idea, and we should file follow-up issues to implement those.
Change:
| ^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused attribute <del> --> $DIR/issue-43106-gating-of-builtin-attrs.rs:55:1 | LL | #![no_mangle] | ^^^^^^^^^^^^^ warning: unused attribute </del> --> $DIR/issue-43106-gating-of-builtin-attrs.rs:56:1 | LL | #![no_link]

Discussion:
Steps to reproduce: 1) make an new crate, set crate type to 2) put a simple function in : 3) build with 4) copy the command line used from above step, and run it as-is example: As you can see, the first time in step 3) has no warnings, however, step 4) cause complains is unused, which isn't true. Step 4) can be replaced by: modify , so that it cause rebuild run again rustc 1.35.0-nightly ( 2019-04-16)
I have same error on today's nightly too
Same for me
I see the same warning text during a build for crate type “staticlib” using nightly 1.36.0 commit 2019-04-18
I will bisect this and then pass the baton to to fix this.
Bisection claims , (). cc
My guess is that should be a attribute? It was declared twice before and the variant got removed.
Also our scheme to track unused attributes does not work the incremental compilation, which is probably why it only happens with that.
cc
A fix is up. I this still nightly only or do we need to backport?
Seems to be nightly-only still
I get this with regular on a crate type with nightly
can you try with the latest nightly? This was only closed yesterday, so today's nightly should contain the fix.
My case () is no longer reproducible on 2019-05-21 nightly.
I no longer see the ~error~ warning with .
Yep it seems it's fixed. sorry I missed that it was merged yesterday. thanks!
Change:
# ignore-cross-compile include ../tools.mk <ins> export LD_LIBRARY_PATH := $(HOST_RPATH_DIR) </ins> all: $(RUSTC) foo.rs -g -O RUSTC="$(RUSTC_ORIGINAL)" $(call RUN,foo)

Discussion:
Running the tests from run-make-fulldeps, I found this one falling It is complaining that , and indeed this file is not in the set in the second one found after . A simple reveals that this file is present in that is included in the first . The second one have , that contains a different , with a different hash () I am not sure if the bug is that the second is missing this directory, or we are calling the wrong that indeed requires the with a different hash.
Do you happen to have any settings? I can't reproduce this with the given command. Does it happen even after an ?
There is a , that once removed comments and empty lines is like: Seems that is reproducible after a clean: Do you think that can be something in the I can experiment dropping features from there.
You are totally correct here. Is the and the parameter. If I set it to I get the error, and I a remove the line I get a succeed. Not clear why.
Hmm, I wonder if is related.
Change:
} Rvalue::Repeat(ref $($mutability)* value, <del> ref $($mutability)* len) => { </del> <ins> _) => { </ins> self.visit_operand(value); <del> self.visit_constant(len); </del> } Rvalue::Ref(r, bk, ref $($mutability)* path) => {

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> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash const L: usize = 4; pub trait Print<const N: usize> { fn print(&self) -> usize { N } } pub struct Printer; impl Print<L> for Printer {} fn main() { let p = Printer; assert_eq!(p.print(), 4); } </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Got same error with: It seems unrelated to the type of the const
claim
Reduced: Looks like a normalization failure to me, but that shouldn't happen for .
So I found the bug, is just outright missing : <hr/But also, it's worrying that an equivalent to this is missing for consts (even if it's not relevant here):
For the record, what I described above () isn't fixed, just worked around. EDIT: opened .
Change:
<ins> // Copyright 2012 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. // Test that we do not see uninformative region-related errors // when we get some basic type-checking failure. See #30580. pub struct Foo { a: u32 } pub struct Pass<'a, 'tcx: 'a>(&'a mut &'a (), &'a &'tcx ()); impl<'a, 'tcx> Pass<'a, 'tcx> { pub fn tcx(&self) -> &'a &'tcx () { self.1 } fn lol(&mut self, b: &Foo) { b.c; //~ ERROR no field with that name was found self.tcx(); } } fn main() {} </ins>

Discussion:
I have encountered this problem several times while compiling versions of rustc with errors, but this is the first self-contained example I have found. A single error as the field does not exist Note the fat cascading region error. This reproduces on 1.5/1.6 and current nightly.
cc
Change:
## Repetition <del> The repetition behavior can seem somewhat magical, especially when multiple names are bound at multiple nested levels of repetition. The two rules to keep in mind are: </del> <ins> The repetition operator follows two principal rules: </ins> <del> 1. the behavior of `$(...)*` is to walk through one "layer" of repetitions, for all of the `$name`s it contains, in lockstep, and </del> <ins> 1. `$(...)*` walks through one "layer" of repetitions, for all of the `$name`s it contains, in lockstep, and </ins> 2. each `$name` must be under at least as many `$(...)*`s as it was matched <del> against. If it is under more, it'll be duplicated, as appropriate. </del> <ins> against. If it is under more, it'll be duplicated, as appropriate. </ins> This baroque macro illustrates the duplication of variables from outer repetition levels.

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
return; } <del> // # Run `cargo test` with `-Zmir-opt-level=4`. cargo.env("MIRIFLAGS", "-O -Zmir-opt-level=4"); if !try_run(builder, &mut cargo) { return; } </del> // # Done! builder.save_toolstate("miri", ToolState::TestPass); } else {

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.
Change:
return; } } <del> let param_env = ty::ParamEnv::empty(); if ty.is_copy_modulo_regions(cx.tcx, param_env) { </del> <ins> if ty.is_copy_modulo_regions(cx.tcx, cx.param_env) { </ins> return; } <del> if type_implements_negative_copy_modulo_regions(cx.tcx, ty, param_env) { </del> <ins> if type_implements_negative_copy_modulo_regions(cx.tcx, ty, cx.param_env) { </ins> return; } if def.is_variant_list_non_exhaustive()

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --This appears to be an issue in the lint, possibly it assuming can be normalized, when due to the bound and the lack of implementation , the type is effectively <!-- 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. --: locally <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Still crashes with , although the Ice is a bit different.
I would appreciate if you opened a new issue for that, and shared the backtrace, etc there instead.
Change:
} pub fn get_path_res(&self, id: NodeId) -> Res { <del> let hir_id = self.tcx.hir().node_id_to_hir_id(id); </del> <ins> // FIXME(#71104) let hir_id = match self.tcx.hir().opt_node_id_to_hir_id(id) { Some(id) => id, None => return Res::Err, }; </ins> match self.tcx.hir().get(hir_id) { Node::TraitRef(tr) => tr.path.res,

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc although I think they might've already seen this?
claim
Change:
rcvr_ty, source_expr.hir_id, ProbeScope::TraitsInScope, <del> ) { </del> <ins> ) else { return; }; // FIXME: `probe_for_name_many` searches for methods in inherent implementations, // so it may return a candidate that doesn't belong to this `revr_ty`. We need to // check whether the instantiated type matches the received one. for _matched_method in candidates { </ins> // found a match, push to stack stack_methods.push(rcvr_ty); }

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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<!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim
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. enum foo { foo(bar) } struct bar { x: bar } //~ ERROR illegal recursive struct type; wrap the inner value in a box to make it representable //~^ ERROR this type cannot be instantiated without an instance of itself fn main() { } </ins>

Discussion:
The following program causes a stack overflow: There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)
Huh, so that's why std::list has pointer indirections in it.
This is still an issue, nominating for production ready
accepted for production-ready milestone
So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.
you have to reference the type, just like , which I triaged today. Actually I think they are the same bug.
This applies to non-infinite-sized types that contain themselves unboxed like the following too:
Accepted for 1.0, P-high.

Here is a test case: I think the right approach is to replace with something like . then we have to keeep a stack of def-ids and when we enter a new nominal type check that we do not already have it on the stack. i started this then realized it was a big distraction from what I'm trying to do, so filing a bug instead. Marking as A-typesystem as this check is performed in
Just to make this concrete: both of the cases that Niko describes yield ICE's. The first (the and items) yields an ICE with no useful error information. The second ( and ) yields an error describing the illegal recursive enum type (followed by an ICE :).
I don't believe this is backwards incompatible, renominating.
accepted for production-ready milestone
appears to be properly classified
Accepting for P-high.
Tagging as mentorship bug, with as mentor
This code triggers the same infinite recursion in typestructurallycontains:
I have a fix for this written, in case anyone is wondering whether to start working on it. I'll submit a pull request soon.
Change:
return false; } <ins> debug!("overlap: subtraitref check succeeded"); </ins> // Are any of the obligations unsatisfiable? If so, no overlap. <del> a_obligations.iter() .chain(b_obligations.iter()) .all(|o| selcx.evaluate_obligation(o)) </del> <ins> let opt_failing_obligation = a_obligations.iter() .chain(b_obligations.iter()) .find(|o| !selcx.evaluate_obligation(o)); if let Some(failing_obligation) = opt_failing_obligation { debug!("overlap: obligation unsatisfiable {}", failing_obligation.repr(selcx.tcx())); return false; } true </ins> } /// Instantiate fresh variables for all bound parameters of the impl

Discussion:
Attempting to compile with and yields the following ICE:
Reduced test case: Still ICEs with The ICE goes away if the on the is changed to a bare instead of a reference.
Slightly different test case: EDIT: Nevermind, it's the same but uses a closure instead of the more general .
I have bisected this issue to rust-lang/rust (from )
A workaround would be simply:
This doesn't help much if you need to call methods that are on the trait (which was on the original code).
cc me
This is blocking collect-rs from compiling.
This is interesting. The culprit is : it registers obligations from implementation's methods into an hybrid parameter environment which has trait's methods in it. In the example given in this issue, when the associate type is projected out, the implementation's method acquires an extra lifetime variable. The trait's method doesn't have it so the lifetime resolution fails in an ICE later on. I'm not sure how to fix that though.
This compiles so at first glance it looks like a viable workaround: But if one tries to really use as an , compiler panics on an assertion failure:
Getting this with some hashing code.

will output something along the lines of: Start hash BYTES: [69, 84, 87, 87, 100, 57, 118, 102, 80, 97, 122, 56, 100, 116, 80, 82, 74, 78, 104, 116, 109, 51, 88, 54, 56, 98, 56, 97, 66, 119, 105, 116, 90, 114, 50, 83, 107, 99, 51, 52, 89, 121, 121, 112, 86, 116, 57, 66, 120, 87, 86, 112, 88, 55, 66, 49, 76, 90, 86, 48, 49, 53, 56, 53, 52, 48, 56, 56, 49, 53, 54, 48, 51] lyra2 finished: CfV9jehQVXsVnx6Vrg5f9VgHVkWeatbrFGxKVz2knfEc Starting argon thread 'certificate::tests::checkcertdiff' panicked at 'index out of bounds: the len is 0 but the index is 31',
Change:
<ins> //@ run-rustfix //@ rustfix-only-machine-applicable //@ check-pass // See <https://github.com/rust-lang/rust/issues/121330>. fn cmp<T: ?Sized>(a: *mut T, b: *mut T) -> bool { let _ = a == b; //~^ WARN ambiguous wide pointer comparison panic!(); } fn main() {} </ins>

Discussion:
No response The lint is marked able but applying the suggestion fails: ` No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same problem with
claim
I think this is a known issue with with applying all suggestions even if they are multually exclusive. I'm pretty sure there's nothing to do in the lint, it correctly suggests the two (valid) suggestions, only one of them should be applied.
Well we can either remove one of the suggestions or make the lint MaybeIncorrect or something?
I think this is We can't remove one of the suggestions, they are both necessary. We can however make them for the time being.
That is indeed unfortunate.
Change:
hi: mir::ConstantKind<'tcx>, end: RangeEnd, span: Span, <ins> lo_expr: Option<&hir::Expr<'tcx>>, hi_expr: Option<&hir::Expr<'tcx>>, </ins> ) -> PatKind<'tcx> { assert_eq!(lo.ty(), ty); assert_eq!(hi.ty(), ty); let cmp = compare_const_vals(self.tcx, lo, hi, self.param_env); <ins> let max = || { self.tcx .layout_of(self.param_env.with_reveal_all_normalized(self.tcx).and(ty)) .ok() .unwrap() .size .unsigned_int_max() }; </ins> match (end, cmp) { // `x..y` where `x < y`. // Non-empty because the range includes at least `x`.

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
use crate::dep_graph::SerializedDepNodeIndex; <del> use crate::mir; </del> use crate::mir::interpret::{GlobalId, LitToConstInput}; use crate::traits; use crate::traits::query::{

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
/// /// Returns 0 for equal, < 0 for less than and > 0 for greater /// than. <del> // FIXME(#32610): Return type should be c_int fn memcmp(s1: *const u8, s2: *const u8, n: usize) -> i32; </del> <ins> fn memcmp(s1: *const u8, s2: *const u8, n: usize) -> ffi::c_int; </ins> } #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?