jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0433]: failed to resolve: there are too many initial `super`s. --> $DIR/impl-items-vis-unresolved.rs:21:13 | LL |         pub(super) fn new() {} |             ^^^^^ there are too many initial `super`s. error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
[submodule "src/binaryen"] path = src/binaryen url = https://github.com/alexcrichton/binaryen.git <ins> [submodule "src/doc/rust-by-example"] path = src/doc/rust-by-example url = https://github.com/rust-lang/rust-by-example </ins>

Discussion:
This is an issue for moving Rust By Example, which is currently at , to . I will be working on the first step shortly. [x] Convert RBE to a submodule under [x] Add RBE to the bookshelf (thanks [x] Update book release process on forge After it is converted and RBE reaches stable: [ ] Update the main English website link a 301
Step one done! Now waiting for this to reach stable.
The forge documentation can be updated now.
This has all been done!
Change:
// We try each or-pattern branch in turn. let mut matrix = matrix.clone(); for v in v.expand_or_pat() { <del> let usefulness = is_useful(cx, &matrix, &v, witness_preference, hir_id, is_under_guard, false); </del> <ins> let usefulness = ensure_sufficient_stack(|| { is_useful(cx, &matrix, &v, witness_preference, hir_id, is_under_guard, false) }); </ins> ret.extend(usefulness); // If pattern has a guard don't add it to the matrix. if !is_under_guard {

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:
<ins> error: future cannot be sent between threads safely --> $DIR/issue-65436-raw-ptr-not-send.rs:12:5 | LL | fn assert_send<T: Send>(_: T) {} |    -----------    ---- required by this bound in `assert_send` ... LL |     assert_send(async { |     ^^^^^^^^^^^ future returned by `main` is not `Send` | = help: within `impl std::future::Future`, the trait `std::marker::Send` is not implemented for `*const u8` note: future is not `Send` as this value is used across an await --> $DIR/issue-65436-raw-ptr-not-send.rs:14:9 | LL |         bar(Foo(std::ptr::null())).await; |         ^^^^^^^^----------------^^^^^^^^- `std::ptr::null()` is later dropped here |         |       | |         |       has type `*const u8` |         await occurs here, with `std::ptr::null()` maybe used later help: consider moving this into a `let` binding to create a shorter lived borrow --> $DIR/issue-65436-raw-ptr-not-send.rs:14:13 | LL |         bar(Foo(std::ptr::null())).await; |             ^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
The following code was working in nightly-2019-09-05, but no longer works in nightly-2019-10-15. The workaround is not quite intuitive. () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm also running into this error using Tide and a DB Pool from Diesel I've managed to get a slightly simpler/different version of the above code - I'd expect this to work because I'd expect the to be finished before the starts (I guess it's similar to how pre-NLL we'd expect function calls in arguments to work but sometimes they wouldn't because existing borrows?) I've managed to track it down to happening somewhere between these - but I'm not sure how to go about figuring this out any further (I've never built the compiler, let alone actually debugged it) This successfully buildsThis fails
This was an intentional change to match the drop order in synchronous code:
This was an intentional change but these errors also look like they are caused by "overapproximation" of the set of captured values. We are working to improve that; separately, we are also working on improving the diagnostics here.
Assigning to myself as this is a case I'd hope to tackle in . It isn't currently handled by that PR, as the current diagnostic improvements only work when the error originates from an , not . claim
I found a similar problem: Is this the same bug?
Unassigning myself since has landed.
adds a compiler message to suggest a workaround for this problem. Is it not possible to make the compiler smarter and not borrow unnecessary variables across ?
rustc is not that smarter yet, we already have an issue tracking this , along with were trying to lint users with "shorten" workaround(might be lifted once the analysis is improved) in these two "common" cases.
It's a matter of having consistent language semantics for async and non-async code. The lang team discussed this and decided the drop order should be consistent (i.e. we shouldn't drop temporaries until the end of the statement, even if the statement contains ).
Change:
pub symbol_gallery: SymbolGallery, /// The parser has reached `Eof` due to an unclosed brace. Used to silence unnecessary errors. pub reached_eof: Lock<bool>, <ins> /// Environment variables accessed during the build and their values when they exist. pub env_depinfo: Lock<FxHashSet<(Symbol, Option<Symbol>)>>, </ins> } impl ParseSess {

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
* The `test` attribute, for marking functions as unit tests. * The `allow`, `warn`, `forbid`, and `deny` attributes, for controlling lint checks. Lint checks supported by the compiler can be found via `rustc -W help`. <ins> * The `deriving` attribute, for automatically generating implementations of certain traits. </ins> Other attributes may be added or removed during development of the language.

Discussion:
As far as i see it, "deriving" is documented neither in the tutorial nor in the manual. Example:
Change:
<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>

Discussion:
<!-- 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
Change:
<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>

Discussion:
I tried this code: Build with With recent nighties it fails to link: This issue does not occur with or . searched nightlies: from nightly-2022-04-24 to nightly-2022-04-28 regressed nightly: nightly-2022-04-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
cc This may potentially be reproducible with too. UPD: It does reproduce on , even on hello-world, if LLD is used as a linker instead of UPD2: needs to have one additional "feature-enabling" symbol on these targets, see in LLD sources.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Thanks for the quick fix!
Change:
location_info, type_param_defs.repr(vcx.tcx()), substs.repr(vcx.tcx())); <del> let _i = indenter(); </del> // We do this backwards for reasons discussed above. assert_eq!(substs.tps.len(), type_param_defs.len());

Discussion:
cc I think this is related to . Here's the example code: It errors with:
I just got similar ICE with extern mod. a.rs: b.rs: Building b.rs gives (Yes, I was using .) It worked on rust revision but not on revision .
Another variant: produces:
Seems likely to be related, yes. I'll take a look today. Probably something funky in the handling of static methods. Possibly related to what was trying to address in (though maybe not -- I'm sad to say I ddn't fully understand the problem there, was too caught up in trying to finish with !)
Here's an example relevant to me:
So these examples are a mix of problems, but they are all related to . The only one of these examples I expect to not ICE is the first one. The others don't work because of . The basic problem is that you cannot have a function which has a lifetime parameter that appears in a trait bound (yet -- I want to fix this, see for details). Interestingly, the reason that we have this problem with the first example, is that static functions like get translated into functions with lifetime parameters that appear within a trait bound. That is, the type for looks to the compiler like: You can see here that appears in the bound for . Anyway, I have the fix for this. This is good because it got me thinking about and I think it's not too hard to extend the fix to cover that case as well. But I'll push the limited fix for just this bug for now.
Thanks for looking into this. I started playing around with your branch to fix this and I ran into another ICE. Is there something new, or is it also caused by ? Errors with:
On Sat, Nov 16, 2013 at 10:01:08PM -0800, Erick Tryzelaar wrote: . I will see how quickly I can prepare a fix for this. The key identifying point is: right here (I a comment)
Change:
// This previously triggered an ICE. pub(in crate::r#mod) fn main() {} <del> //~^ ERROR expected module, found unresolved item </del> <ins> //~^ ERROR failed to resolve: maybe a missing crate `r#mod` </ins>

Discussion:
Example: Found by crater run (https://crater-) when visibility resolution switched to a different algorithm (early resolution), which doesn't have this problem.
This is a regression from Rust 1.33.
Diagnostic improvements strike again:
Fixed in
Change:
ty::Predicate::Trait(ref data) => { let trait_obligation = obligation.with(data.clone()); <del> if data.is_global() && !data.has_late_bound_regions() { </del> <ins> if data.is_global() { </ins> // no type variables present, can use evaluation for better caching. // FIXME: consider caching errors too. if self.selcx.infcx().predicate_must_hold(&obligation) {

Discussion:
This is a regression between rustc 1.20.0 and 1.21.0. 20 correctly rejects this code with the following error.
Tagging P-high because this very much affects Serde.
Same issue using Serde traits: (One possible) output:
Even better, :
Perhaps we can bisect this regression? (e.g., with )
Bisected to correct behavior in nightly-2017-07-07 -- rustc 1.20.0-nightly ( 2017-07-06), incorrect behavior in nightly-2017-07-08 -- rustc 1.20.0-nightly ( 2017-07-07). That range is Looks like
visited for triage. Assigning to
thanks, very helpful!
I think the bug is here: In particular, I think the condition is not strong enough. doesn't consider region annotations, so we probably need to not use this logic if there are any regions. But I'm wondering if the whole concept is flawed. I'm a bit fearful of regions being introduced through associated type normalization.
I have a fix.
Of course, any approach that relies on any lifetimes in the affected trait-ref is fatally flawed - here's an example where the trait ref is the region-free .
I'm not really sure what your example is meant to illustrate. That said, running that on my branch gives an error: This seems like the error I would expect, more or less. We try to use the impl to prove that but we fail to do so (because of the side condition that it adds).
BTW, the check looks like it happened because I used there, and an explicit check when he changed in to note be made true by late-bound regions.
visited for triage. bug seems to be being dealt with, assuming that PR is eventually deemed as passing muster...
Yes, I think that the "no late-bound regions" check was basically a workaround for this same problem; I removed it in the PR since I think it has a "more correct" fix.
Change:
<ins> // https://github.com/rust-lang/rust/issues/126389 mod a { pub mod b { pub mod c {} } } use a::*; use b::c; //~^ ERROR: unresolved import `b::c` //~| ERROR: cannot determine resolution for the import //~| ERROR: cannot determine resolution for the import use c as b; fn c() {} fn main() { } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: inconsistent resolution for an import', 'error: internal compiler error: inconsistent resolution for an import' 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: [resolverforlowering_raw] getting the resolver for lowering --
Isn't this example identical to EDIT: oh I see, the PR that closes doesn't actually have this test, so it's possible this is a different ICE.
This one has an additional which indeed causes the ICE to trigger again :laughing:
Regression in nightly-2020-11-09 commit[0] 2020-11-07: Auto merge of - Mark-Simulacrum:debug-asserts, r=pietroalbini commit[1] 2020-11-07: Auto merge of - Mark-Simulacrum:revert-, r=petrochenkov commit[2] 2020-11-08: Auto merge of - petrochenkov:mergetarg, r=Mark-Simulacrum commit[3] 2020-11-08: Auto merge of - lcnr:revert75443, r=nikomatsakis commit[4] 2020-11-08: Auto merge of - m-ou-se:rollup-3jp1ijj, r=m-ou-se commit[5] 2020-11-08: Auto merge of - petrochenkov:visitok, r=Aaron1011

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' 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: [resolverforloweringraw] getting the resolver for lowering --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc as this looks 99% like and you fixed that one recently ^^
claim. I will investigate it in my spare time.
Change:
}); } for (krate, path, default) in krates("rustc-main") { <ins> // We hijacked the `src/rustc` path above for "build just the compiler" // so let's not reinterpret it here as everything and redirect the // `src/rustc` path to a nonexistent path. let path = if path == "src/rustc" { "path/to/nowhere" } else { path }; </ins> rules.build(&krate.build_step, path) .dep(|s| s.name("libtest")) .dep(move |s| s.name("llvm").host(&build.config.build).stage(0))

Discussion:
(In this example and ) This part: seems unnecessary as that compiler won't be used in the bootstrap (in fact, it can be executed by the build machine due to the differences in architectures) and it's not the requested rustc either. cc
Also it seems the wrong is being copied into the output directory: should be not , right?
Hm ok some of this is expected, some of this isn't expected. I can't seem to quite make sense of your original logs, though. Are you sure that was executed exactly to produce that trace? I unfortunately can't seem to reconstruct the sequence of events on master that'd lead to that.
repro as a shell script
Ok addressed in (this path redirected to the wrong step) but it'll need as well to be maximally effective.
Change:
<ins> #![deny(unknown_or_malformed_diagnostic_attributes)] #[diagnostic::unknown_attribute] //~^ERROR unknown diagnostic attribute struct Foo; fn main() {} </ins>

Discussion:
When compiling my feature and is included I got the attached ICE. The following is the unstable configuration is the repository this occurs on. I will get a minimal verifiable example setup shortly. <details<summaryBacktrace</summary<p</p</details
Here is the full ICE output:
Turns out I was missing in my deny list. Not sure if that should be an ICE or not, feel free to close if that is expected behavior. This wasn't a fix, the behavior still happened.
Does this specifically only happen with clippy, or does this ICE also happen with a regular /? The backtrace and the fact that these are all rustc lints/features makes me think it's a bug in the compiler
and both produce the same ICE.
Moving to rust-lang/rust in that case, since it sounds like fixing this requires changes in the compiler and we can't do much about that on the clippy side
From what I can tell, MCVE is or, alternatively,
searched nightlies: from nightly-2024-01-01 to nightly-2024-03-12 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsProbably , cc
I filled to address this
Change:
pub fn append_test() { assert @[1,2,3] + @[4,5,6] == @[1,2,3,4,5,6]; } <ins> #[test] pub fn test_from_owned() { assert from_owned::<int>(~[]) == @[]; assert from_owned(~[true]) == @[true]; assert from_owned(~[1, 2, 3, 4, 5]) == @[1, 2, 3, 4, 5]; assert from_owned(~[~"abc", ~"123"]) == @[~"abc", ~"123"]; assert from_owned(~[~[42]]) == @[~[42]]; } #[test] pub fn test_from_slice() { assert from_slice::<int>([]) == @[]; assert from_slice([true]) == @[true]; assert from_slice([1, 2, 3, 4, 5]) == @[1, 2, 3, 4, 5]; assert from_slice([@"abc", @"123"]) == @[@"abc", @"123"]; assert from_slice([@[42]]) == @[@[42]]; } </ins>

Discussion:
Currently has constructor functions including , , , and . As far as I understand, none of these allow constructing an by moving (rather than copying) all the values from a ~vec. Therefore, I think it would be good if gained a function like: and, for convenience, something like this too: Is this proposal something desirable? If so I will try and submit code/docs/tests.
I merged 's change in