jiebi/CodeConvo huggingface dataset:
Change:
<ins> // edition: 2021 // compile-flags: --extern issue_85992_extern_1 --extern issue_85992_extern_2 // aux-build: issue-85992-extern-1.rs // aux-build: issue-85992-extern-2.rs issue_85992_extern_1::m!(); use crate::issue_85992_extern_2; //~^ ERROR unresolved import `crate::issue_85992_extern_2` fn main() {} </ins>

Discussion:
Exact code unknown code. The error was generated by using . Rerunning after did not fix this. Did not resolve this yet at the time of writing this. This might be related to: But I think this was because I compiles first and got this error: This was expected to give an error (needed to be ) <details<summary<strongFull backtrace on the fist check:</strong</summary<p</p</details: Problem persists after updating to last nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace (After trying to recheck it)</strong</summary<p</p</details
I just found out the problem exists because of: If I comment out that line it will not report an internal error anymore. I had a function but I also use the crate  I now renamed the function but still getting errors. So it is likely because of a ambiguity issue. Trying to reproduce it in minimal code example, but not yet been able to do so.
After some testing a narrowed it down to the following: : : My guess why this fails: The macro uses inside of it. But when I try to export this it can not find it. commenting out/removing any line will give a normal compile error. I hope this helps to find out the problem. The error always happens and can thus be reliably reproduced. I tested this on latest nightly too:
reduced:
Hi can you assign it to me? I would like to give it a try and solve it.
Change:
<ins> // check-pass // force-host // no-prefer-dynamic // compile-flags: --crate-type proc-macro #![deny(rustdoc::broken_intra_doc_links)] extern crate proc_macro; use proc_macro::*; /// [`Unpin`] #[proc_macro_derive(F)] pub fn derive_(t: proc_macro::TokenStream) -> proc_macro::TokenStream { t } /// [`Vec`] #[proc_macro_attribute] pub fn attr(t: proc_macro::TokenStream, _: proc_macro::TokenStream) -> proc_macro::TokenStream { t } /// [`std::fs::File`] #[proc_macro] pub fn func(t: proc_macro::TokenStream) -> proc_macro::TokenStream { t } </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 ran with this code: I expected to see this happen: intra-doc-links work and no warning Instead, this happened: intra-doc-links is not working in the generated docs. <img width="215" alt="doc" src="https://user-"And I got brokenintradoc_links warnings: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2023-02-11 <img width="215" alt="doc-old" src="https://user-"<!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
Fixed in
label A-intra-doc-links
Change:
// We've encountered an `AnonConst` in some path, so we need to // figure out which generic parameter it corresponds to and return // the relevant type. <del> let (arg_index, segment) = path </del> <ins> let filtered = path </ins> .segments .iter() .filter_map(|seg| seg.args.map(|args| (args.args, seg)))

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting another error, so low priority. Affected versions: I tried nightly 2021-11-25 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will give this a try claim
Change:
<del> // check-pass </del> <ins> // build-pass </ins> // edition:2018 // This test is derived from

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</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .
Change:
<ins> error: unexpected expression: `5z` --> $DIR/issue-104620.rs:3:16 | LL | #![rustc_dummy=5z] |                ^^ error: aborting due to previous error </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</detailsRegression in nightly-2022-11-18 from ()
This makes me wonder if we could just create a superset of a set of chars and feed these into rustc, hmm.
Can we just here?
cc
I'll take a look, thanks for the heads up.
I changed the test input to the following, to avoid an "expected item after attributes" error: With rust 1.64.0 I get these errors: If I change to return if fails, then I get these errors: Do you think that is reasonable behaviour?
Both seem fine, I'd do whatever is simpler to implement.
Change:
#[inline] fn plain_summary_line(s: Option<&str>) -> String { <del> let line = shorter(s).replace("n", " "); markdown::plain_summary_line(&line[..]) </del> <ins> let md = markdown::plain_summary_line(s.unwrap_or("")); shorter(Some(&md)).replace("n", " ") </ins> } fn document(w: &mut fmt::Formatter, cx: &Context, item: &clean::Item) -> fmt::Result {

Discussion:
There are times it's nice to be able to include a link in the description of a given item. At present, however, if you try to include a reference link, it fails. Rust: HTML for the item description: However, if you change the first line of the Rust to be an inline reference, the problem goes away. Rust: Generated HTML: It appears (I haven't had a chance to check the implementation yet) that rustdoc is only parsing the first Markdown block element, rather than only keeping the first block element. This probably slightly improves performance, but it produces unexpected results.
Change:
self.fold_item_recur(item) } } <ins> enum CodeBlockInvalid { SyntaxError, Empty, } </ins>

Discussion:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.
Change:
cvt(copy_file_range(INVALID_FD, ptr::null_mut(), INVALID_FD, ptr::null_mut(), 1, 0)) }; <del> if matches!(result.map_err(|e| e.raw_os_error()), Err(Some(libc::EBADF))) { </del> <ins> if matches!(result.map_err(|e| e.raw_os_error()), Err(Some(EBADF))) { </ins> HAS_COPY_FILE_RANGE.store(AVAILABLE, Ordering::Relaxed); } else { HAS_COPY_FILE_RANGE.store(UNAVAILABLE, Ordering::Relaxed);

Discussion:
While updating my code base from 1.49 to 1.50 we noticed a failures in a program that rebuilds files from small chunks. We are opening a file in append mode, one in read mode, and we stream one into the other (as for the snippet below). Testing this out confirmed that the error happens on the reader file when the writer is in append mode, whenever we use a / or not. If we load the whole file into a string and then use on the same data it works as intended, as does setting the file in write mode (while it becomes necessary to seek to the end). Checking what got shipped into 1.50 we suspect the probable culprit to be What we are guessing is that this change is using the syscall that doesn't support files in append mode even when the file is in append mode, triggering the Bad File Descriptor error I tried this code (): I expected to see this happen: the files to be concatenated Instead, this happened: returns Strace for the code snipped: Example that works with loading the file into a string before copy (): It most recently worked on: 1.49 50 : no backtrace <!-- 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-stable-regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
syscall326 is copyfilerange. And indeed, it has this error code overloading the more common meaning of EBADF. assign.
Error: Parsing assign command in failed: ...'ot assign.' ''... Please let know if you're having trouble with this bot.
claim
If you need a workaround for the moment you can do which should defeat the incorrect optimizations by going through a trait object so it can't see it's dealing with a file.
Nice, this is awesome. We will try this tomorrow which should allow to migrate our codebase to 1.50! Thanks a lot for the quick help on this..
Test out the workaround and it works, while we wait for the actual fix to come out, thanks a lot!

label +T-libs-impl +I-prioritize +regression-from-stable-to-stable +C-bug +O-linux workaround is available. fix needs review.
Assigning as discussed as part of the and removing . label -I-prioritize +P-critical
Not sure if this is related, but I have a smaller code which also fails with EBADF: Tested with Rust 1.41.1, stable, nightly on Debian 9 and Rust 1.41.1 on Debian 10. Also, the trick with doesn't work in this case.
Totally unrelated and not a bug. opens a file in write-only mode, then you try to read from it later. Use to create read-write files.
lol, just figured it out and wanted to post. Thanks anyway! It's still strange it's EBADF instead of EPERM.
Change:
<ins> error[E0582]: binding for associated type `Output` references an anonymous lifetime, which does not appear in the trait input types --> $DIR/issue-62200.rs:11:39 | LL | fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} |                                       ^^^^^^^^^^^^^^^ | = note: lifetimes appearing in an associated type are not considered constrained error: aborting due to previous error For more information about this error, try `rustc --explain E0582`. </ins>

Discussion:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to
Change:
<ins> // Copyright 2013 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. // Issue #7580 // error-pattern:fail works #[feature(globs)]; use std::*; fn main() { str::with_capacity(10); // avoid an unused import message fail!("fail works") } </ins>

Discussion:
Minimal test case: rustc output: Rust 0.7, Ubuntu 13.04, 64-bit.
Funny. This is because std exports an inner module called std that shadows std.
There are probably other lurking bugs due to this.
This evil inner module is still around. We couls probably just special case the macro injection via an attribute like .
This could probably use a similar fix as , something at the top of the file which says that the path to is.
Fixed by the privacy changes that meant that module in can be private. This works: Flagging as needstest.
Change:
return Err(0); } <del> let color = config::parse_color(matches); let config::JsonConfig { json_rendered, json_unused_externs, .. } = config::parse_json(matches); let error_format = config::parse_error_format(matches, color, json_rendered); let codegen_options = CodegenOptions::build(matches, error_format); let debugging_opts = DebuggingOptions::build(matches, error_format); let diag = new_handler(error_format, None, &debugging_opts); // check for deprecated options check_deprecated_options(matches, &diag); </del> let mut emit = Vec::new(); for list in matches.opt_strs("emit") { for kind in list.split(',') {

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this command: I expected to see this happen: rustdoc shows a warning, the way it does for any other value you pass to : Instead, this happened: Rustdoc gives no warning and lists all passes. <!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: Move this check earlier to before is processed:
claim
Change:
<ins> // check-pass use std::marker::PhantomData; pub struct MyGenericType<T> { _marker: PhantomData<*const T>, } pub struct MyNonGenericType; impl<T> From<MyGenericType<T>> for MyNonGenericType { fn from(_: MyGenericType<T>) -> Self { todo!() } } pub trait MyTrait { const MY_CONSTANT: i32; } impl<T> MyTrait for MyGenericType<T> where Self: Into<MyNonGenericType>, { const MY_CONSTANT: i32 = 1; } impl<T> MyGenericType<T> { const MY_OTHER_CONSTANT: i32 = <MyGenericType<T> as MyTrait>::MY_CONSTANT; } fn main() {} </ins>

Discussion:
I tried this code: I expected to see this happen: It should compile successfully. Instead, this happened: The compiler doesn't realize that is implemented for all and reports an error. Interestingly enough, removing the bound makes this compile again. searched nightlies: from nightly-2021-12-01 to nightly-2021-12-25 regressed nightly: nightly-2021-12-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details modify labels: +regression-from-stable-to-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
CC as the author of the relevant PR.
Fixed by , this one is more interesting than the test I in that PR, as it is stable code (but uses ), so I think we could add this one as an ui test as well.
I can confirm that this is fixed on the latest nightly.
It's E-needs-test because someone should add an ui test for this issue
I'm interested in working on this. Could you tell me where should the test be ? It seems to be somewhere inside .
I might go with . There isn't really much dark magic to picking which directory to file something under; there are a few directories that aren't really used anymore, but other than that, it's just a matter of picking something that makes sense.
claim
Change:
/// contexts around the same size. n_llvm_insns: Cell<usize>, <ins> /// Depth of the current type-of computation - used to bail out type_of_depth: Cell<usize>, </ins> trait_cache: RefCell<FnvHashMap<ty::PolyTraitRef<'tcx>, traits::Vtable<'tcx, ()>>>, }

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
<ins> #![allow(incomplete_features)] #![feature(generic_const_exprs)] trait Bar<const N: usize> {} trait Foo<'a> { const N: usize; type Baz: Bar<{ Self::N }>; //~^ ERROR: unconstrained generic constant } fn main() {} </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 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: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
// check-pass <del> // compile-flags: --emit=mir,link </del> <ins> // compile-flags: --emit=mir,link -Zmir-opt-level=4 </ins> // Checks that we don't ICE due to attempting to run const prop // on a function with unsatisifable 'where' clauses

Discussion:
File: mvce: original: Version information Command: Program output:
cc
I spent some time digging this, but I have no clue how is this happening yet.
Uh... isn't this regression from one of the dataflow const prop PRs? I don't think the is_global change caused
cc
When I reverted changes to problem disappeared. Edit: My hunch is this problem existed before but somehow covered it.
Change:
/// `cfg(...)`'s that are feature gated. const GATED_CFGS: &[GatedCfg] = &[ // (name in cfg, feature, function to check if the feature is enabled) <ins> (sym::overflow_checks, sym::cfg_overflow_checks, cfg_fn!(cfg_overflow_checks)), </ins> (sym::target_abi, sym::cfg_target_abi, cfg_fn!(cfg_target_abi)), (sym::target_thread_local, sym::cfg_target_thread_local, cfg_fn!(cfg_target_thread_local)), (

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue: