jiebi/CodeConvo huggingface dataset:
Change:
#![crate_name = "compiletest"] <del> #![feature(test)] </del> #![deny(warnings)] <ins> // The `test` crate is the only unstable feature // allowed here, just to share similar code. #![feature(test)] </ins> extern crate test;

Discussion:
See . Unfortunately the "fix" to that bug breaks the build when building using 1.31.0 and you have to unapply the patch to make it work against 1.31.0. e.g. from : ~ The problem here is that if stage0 is 1.31.0 then the patch MUST be unapplied, if stage0 is 1.32.0 then the patch MUST be applied. Obviously we can't do both at once. However in both Debian and Fedora we occasionally use either the current or the previous version of rustc to build a given version of rustc, and both of these versions should work. cc
Doing things this way (using stage2) would also have ensured that was detected early, and never made it into a release.
We would prefer to build tools such as compiletest with the bootstrap compiler because stage1, stage2 compilers take a long time to build. I think largely we just can't at this point support building with multiple compilers -- i.e., the bootstrap compiler should be the same one we use in tree. We just don't have the CI budget and resources to test and support multiple versions of the compiler for crates using unstable features. As such, I think the only resolution here will be to close this... cc and though since this is somewhat of a policy type decision (and we don't have a firm policy AFAIK).
As a matter of policy, we do need such rebuild-bootstrapping to continue to be supported to some extent, even if it's only a "tier-2" use case. That is, fixing these sort of issues reactively is still better than nothing.
Is conditional compilation based on the compiler version possible in Rust today? That could be an alternative solution, instead of always using stage2. The language is a bit technical and I couldn't figure it out.
I guess for now, I could hack that sort of logic into the Debian build script manually in an ad-hoc way - applying the patch vs not, based on the stage0 compiler version.

I think if we wanted to solve this issue the best way to do it would be to: Require compiles on stable, except for the dependency on the crate Have depend on std/test in-tree binaries, so we always build them (with the stage0 compiler) That way works with rebuild-bootstraping and normal use cases because it's not using anything unstable except libtest, which is built from source to link against and already solves this problem otherwise.
I think in general a policy of unstable tools/dependencies having the requirement of being in-tree deps instead of beta is reasonable, yeah. I can try to make a patch that makes compiletest (and if there are any other such tools) do this sometime this week.
Same issue with 1.40.0 again, when using itself as stage0: ~ CC AFAICT you do not have a patch that fixes this on Fedora either.
For 1.40.0 the relevant commit to conditionally-apply or not is . For the upcoming 1.41.0 (or is it 1.42.0) stable release it seems we will have to do the same thing for .
Change:
<del> error: compilation successful --> $DIR/dropck.rs:16:1 </del> <ins> error[E0597]: `ref_` does not live long enough --> $DIR/dropck.rs:22:11 </ins> | <del> LL | / fn main() { #![rustc_error] // rust-lang/rust#49855 LL | |     let (cell, mut gen); LL | |     cell = Box::new(RefCell::new(0)); LL | |     let ref_ = Box::leak(Box::new(Some(cell.borrow_mut()))); ...  | LL | |     // drops the RefCell and then the Ref, leading to use-after-free LL | | } | |_^ </del> <ins> LL |       gen = || { |  ___________^ LL | |         // but the generator can use it to drop a `Ref<'a, i32>`. LL | |         let _d = ref_.take(); //~ ERROR `ref_` does not live long enough LL | |         yield; LL | |     }; | |_____^ borrowed value does not live long enough ... LL |   } |   - |   | |   borrowed value only lives until here |   borrow later used here, when `gen` is dropped </ins> error: aborting due to previous error <ins> For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
.define("LLVM_TARGETS_TO_BUILD", llvm_targets) .define("LLVM_EXPERIMENTAL_TARGETS_TO_BUILD", llvm_exp_targets) .define("LLVM_INCLUDE_EXAMPLES", "OFF") <del> .define("LLVM_INCLUDE_TESTS", "OFF") </del> .define("LLVM_INCLUDE_DOCS", "OFF") .define("LLVM_INCLUDE_BENCHMARKS", "OFF") .define("LLVM_ENABLE_TERMINFO", "OFF")

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
<ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-83753-invalid-associated-type-supertrait-hrtb.rs:5:21 | LL |     fn bar(foo: Foo<Target = usize>) {} |                     ^^^^^^^^^^^^^^ associated type not allowed here error: aborting due to previous error For more information about this error, try `rustc --explain E0229`. </ins>

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. --<!-- 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
From
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
// FIXME(#43408) always enable this once `lazy_normalization` is // stable enough and does not need a feature gate anymore. Node::AnonConst(_) => { <del> let parent_def_id = tcx.hir().get_parent_item(hir_id); </del> <ins> let parent_did = tcx.parent(def_id.to_def_id()); // We don't do this unconditionally because the `DefId` parent of an anon const // might be an implicitly created closure during `async fn` desugaring. This would // have the wrong generics. // // i.e. `async fn foo<'a>() { let a = [(); { 1 + 2 }]; bar().await() }` // would implicitly have a closure in its body that would be the parent of // the `{ 1 + 2 }` anon const. This closure's generics is simply a witness // instead of `['a]`. let parent_did = if let DefKind::AnonConst = tcx.def_kind(parent_did) { parent_did } else { tcx.hir().get_parent_item(hir_id).to_def_id() }; debug!(?parent_did); </ins> let mut in_param_ty = false; for (_parent, node) in tcx.hir().parent_iter(hir_id) {

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:
pub exported_macros: Vec<P<ast::Item>>, pub syntax_env: SyntaxEnv, <ins> pub recursion_count: uint, </ins> } impl<'a> ExtCtxt<'a> {

Discussion:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows.

If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()
Change:
// But the system is limited -- make sure we successfully set a truncation. let mut buf = vec![0u8; long_name.len() + 1]; unsafe { <del> libc::pthread_getname_np(libc::pthread_self(), buf.as_mut_ptr().cast(), buf.len()); } </del> <ins> libc::pthread_getname_np(libc::pthread_self(), buf.as_mut_ptr().cast(), buf.len()) }; </ins> let cstr = CStr::from_bytes_until_nul(&buf).unwrap(); assert!(cstr.to_bytes().len() >= 15); // POSIX seems to promise at least 15 chars assert!(long_name.as_bytes().starts_with(cstr.to_bytes())); <ins> // Also test directly calling pthread_setname to check its return value. assert_eq!(set_thread_name(&cstr), 0); // But with a too long name it should fail. assert_ne!(set_thread_name(&CString::new(long_name).unwrap()), 0); </ins> }); result.unwrap().join().unwrap(); }

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
{ let opaque_ty = tcx.fold_regions(unshifted_opaque_ty, |re, _depth| { match re.kind() { <del> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReError(_) => re, </del> <ins> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReError(_) | ty::ReStatic => re, </ins> r => bug!("unexpected region: {r:?}"), } });

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. --<!-- 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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Regression in
Change:
<ins> // revisions:rpass1 rpass2 // compile-flags: --crate-type cdylib // skip-codegen #![deny(unused_attributes)] #[no_mangle] pub extern "C" fn rust_no_mangle() -> i32 { 42 } </ins>

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:
<ins> const fn test_me<T>(a: usize) -> usize { const { a } //~^ ERROR:  attempt to use a non-constant value in a constant } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-genericconstexprs
Huhu, the master artifacts -v is super confusing since the nightly date is incorrect I don't think cargo-bisect-rustc would work on that. Anyway it's ofc, nothing much else has landed since the nightly was cut. label -F-genericconstexprs +F-inline_const
ah, I would just look at the commit hash given by rustc :sweat_smile:
Change:
// surface that there was an error in this worker. bomb.result = { let _prof_timer = cgcx.prof.generic_activity(work.profiling_event_id()); <del> execute_work_item(&cgcx, work).ok() </del> <ins> Some(execute_work_item(&cgcx, work)) </ins> }; }); }

Discussion:
Ok, so rustc outputting to /dev/null is a bit pathelogical but it used to not ICE the compiler. If you checkout and from dir tests/suite/futurescore run: rustc --crate-type lib -o /dev/null Then rustc is vexed: (ICEs on stable and nightly) The irony is that this is in the test suite of a rust code minimisation project.... Let me minimise the reproduction of the problem...
Thanks to rust-reduce I managed to get the repro down to: Interestingly it doesn't ICE on playground - I'm guessing playground is on linux?
Indeed
triage: P-medium, removing nomination tag, assigning self.
hmm. I nonetheless see an ICE on my own Linux machine. (There is probably some other reason the ICE does not replicate on the playpen.)
Change:
}; let replacement = visibility_qualified(&item.vis, &base_replacement); tcx.struct_span_lint_node(lint, id, extern_crate.span, msg) <del> .span_suggestion_short(extern_crate.span, &help, replacement) </del> <ins> .span_suggestion_short_with_applicability( extern_crate.span, &help, replacement, Applicability::MachineApplicable, ) </ins> .emit(); } }

Discussion:
Migrated from It's been mentioned/requested multiple times on the that should remove the statements when moving to Rust 2018. One of the big draws of Rust 2018's module system is that all of the "redundant" lines can finally be removed. It took some of the excitement away when I went through all of the steps and still saw them there. I think it will just be a better experience for users to see one of the tangible benefits of this change. As it is right now, they just see the in front of all of their local imports and they might not realize what a nice change the module system updates really are. After I manually removed the 's I did get my satisfying result , but let's give this to users on the first go around. If I understand correctly this should be implemented in the compiler under the lints, rather than itself. cc
I'm moving this forward up on the milestone list due to just having closed in favor of this issue, which was itself on the RC milestone.
Ok so I've some triaging of related lint issues, and I believe the current work items are: A rustfix-fixable suggestion for removing needs to be implemented. The implementation would . Currently the lint suggests switching to simply . While technically correct and handles lots of corner cases, this doesn't achieve the desired goal of actually removing annotations. We can't blanket remove all statements, for example is correctly warned to use a rather than deleting the statement outright. I'm testing out some ideas locally as well.
I believe this should be fixed by , I think the naive solution actually works well!
Change:
<ins> error[E0277]: the trait bound `{integer}: Test` is not satisfied --> $DIR/on_unimplemented_ice.rs:16:14 | LL |     breakage(1); |     -------- ^ the trait `Test` is not implemented for `{integer}` |     | |     required by a bound introduced by this call | note: required by a bound in `breakage` --> $DIR/on_unimplemented_ice.rs:12:16 | LL | fn breakage<T: Test>(_: T) {} |                ^^^^ required by this bound in `breakage` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

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. --The simplest version uses / however I have also tested this via a sub-crate. : : <!-- 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 can also reproduce this on and on and . When running <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Change:
module_path.push(Segment { ident: Ident { name: kw::PathRoot, span: source.ident.span }, id: Some(self.r.next_node_id()), <ins> has_generic_args: false, </ins> }); source.ident.name = crate_name; }

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
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) } enum bar { bar_none, bar_some(bar) } //~ ERROR illegal recursive enum type; wrap the inner value in a box to make it representable 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.