jiebi/CodeConvo huggingface dataset:
Code change:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this

Related discussion:
text: } } <ins> /// Checks that generic parameters are in the correct order, /// which is lifetimes, then types and then consts. (`<'a, T, const N: usize>`) </ins> fn validate_generic_param_order<'a>( sess: &Session, handler: &rustc_errors::Handler,
Code change:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this

Related discussion:
text: <ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Bad<const N: usize, T> { //~ ERROR type parameters must be declared prior arr: [u8; { N }], another: T, } fn main() { } </ins>
Code change:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this

Related discussion:
text: <ins> error: type parameters must be declared prior to const parameters --> $DIR/argument_order.rs:4:28 | LL | struct Bad<const N: usize, T> { |           -----------------^- help: reorder the parameters: lifetimes, then types, then consts: `<T, const N: usize>` warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/argument_order.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: aborting due to previous error </ins>
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: // The collapse-docs pass won't combine sugared/raw doc attributes, or included files with // anything else, this will combine them for us. if let Some(doc) = attrs.collapsed_doc_value() { <del> self.collector.set_position(attrs.span.unwrap_or(DUMMY_SP)); </del> <ins> // Use the outermost invocation, so that doctest names come from where the docs were written. let span = attrs .span .map(|span| span.ctxt().outer_expn().expansion_cause().unwrap_or(span)) .unwrap_or(DUMMY_SP); self.collector.set_position(span); </ins> markdown::find_testable_code( &doc, self.collector,
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: <ins> #[macro_export] macro_rules! attrs_on_struct { ( $( #[$attr:meta] )* ) => { $( #[$attr] )* pub struct ExpandedStruct; } } </ins>
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: <ins> // edition:2018 // aux-build:extern_macros.rs </ins> // compile-flags:--test --test-args=--test-threads=1 // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // check-pass
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: //! assert_eq!(1 + 1, 2); //! ``` <ins> extern crate extern_macros as macros; use macros::attrs_on_struct; </ins> pub mod foo { /// ```
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: /// ``` pub fn bar() {} } <ins> attrs_on_struct! { /// ``` /// assert!(true); /// ``` } </ins>
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: <del> running 2 tests test $DIR/doctest-output.rs - (line 5) ... ok test $DIR/doctest-output.rs - foo::bar (line 11) ... ok </del> <ins> running 3 tests test $DIR/doctest-output.rs - (line 7) ... ok test $DIR/doctest-output.rs - ExpandedStruct (line 23) ... ok test $DIR/doctest-output.rs - foo::bar (line 17) ... ok </ins> <del> test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out </del> <ins> test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out </ins>
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: } /// Configuration for compiletest <del> #[derive(Clone)] </del> <ins> #[derive(Debug, Clone)] </ins> pub struct Config { /// `true` to to overwrite stderr/stdout files instead of complaining about changes in output. pub bless: bool,
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: emit_metadata: EmitMetadata, allow_unused: AllowUnused, ) -> Command { <del> let is_rustdoc = self.is_rustdoc(); </del> <ins> let is_aux = input_file.components().map(|c| c.as_os_str()).any(|c| c == "auxiliary"); let is_rustdoc = self.is_rustdoc() && !is_aux; </ins> let mut rustc = if !is_rustdoc { Command::new(&self.config.rustc_path) } else {
Code change:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.

Related discussion:
text: } } <ins> #[derive(Debug)] </ins> enum TargetLocation { ThisFile(PathBuf), ThisDirectory(PathBuf),
Code change:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

Related discussion:
text: <ins> // Regression test for https://github.com/rust-lang/rust/issues/56445#issuecomment-629426939 // check-pass #![crate_type = "lib"] use std::marker::PhantomData; pub struct S<'a> { pub m1: PhantomData<&'a u8>, pub m2: [u8; S::size()], } impl<'a> S<'a> { pub const fn size() -> usize { 1 } pub fn new() -> Self { Self { m1: PhantomData, m2: [0; Self::size()], } } } </ins>
Code change:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

Related discussion:
text: <ins> // check-pass pub struct A<'a>(&'a ()); impl<'a> A<'a> { const N: usize = 68; pub fn foo(&self) { let _b = [0; Self::N]; } } fn main() {} </ins>
Code change:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

Related discussion:
text: <ins> #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] fn main() { const C: impl Copy = 0; match C { C | _ => {} //~ ERROR: opaque types cannot be used in patterns } } </ins>
Code change:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

Related discussion:
text: <ins> error: opaque types cannot be used in patterns --> $DIR/issue-71042-opaquely-typed-constant-used-in-pattern.rs:7:9 | LL |         C | _ => {} |         ^ error: aborting due to previous error </ins>
Code change:
gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

Related discussion:
text: <ins> // check-pass #![feature(type_alias_impl_trait)] pub type Successors<'a> = impl Iterator<Item = &'a ()>; pub fn f<'a>() -> Successors<'a> { None.into_iter() } pub trait Tr { type Item; } impl<'a> Tr for &'a () { type Item = Successors<'a>; } pub fn kazusa<'a>() -> <&'a () as Tr>::Item { None.into_iter() } fn main() {} </ins>