jiebi/CodeConvo huggingface dataset:
Code change:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

Related discussion:
text: use rustc_hir::lang_items::{ FutureTraitLangItem, PinTypeLangItem, SizedTraitLangItem, VaListTypeLangItem, }; <del> use rustc_hir::{ExprKind, GenericArg, HirIdMap, Item, ItemKind, Node, PatKind, QPath}; </del> <ins> use rustc_hir::{ExprKind, GenericArg, HirIdMap, ItemKind, Node, PatKind, QPath}; </ins> use rustc_index::bit_set::BitSet; use rustc_index::vec::Idx; use rustc_infer::infer;
Code change:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

Related discussion:
text: "packed type cannot transitively contain a `#[repr(align)]` type" ); <del> let hir = tcx.hir(); let hir_id = hir.as_local_hir_id(def_spans[0].0.expect_local()); if let Node::Item(Item { ident, .. }) = hir.get(hir_id) { err.span_note( tcx.def_span(def_spans[0].0), &format!("`{}` has a `#[repr(align)]` attribute", ident), ); } </del> <ins> err.span_note( tcx.def_span(def_spans[0].0), &format!( "`{}` has a `#[repr(align)]` attribute", tcx.item_name(def_spans[0].0) ), ); </ins> if def_spans.len() > 2 { let mut first = true; for (adt_def, span) in def_spans.iter().skip(1).rev() { <del> let hir_id = hir.as_local_hir_id(adt_def.expect_local()); if let Node::Item(Item { ident, .. }) = hir.get(hir_id) { err.span_note( *span, &if first { format!( "`{}` contains a field of type `{}`", tcx.type_of(def.did), ident ) } else { format!("...which contains a field of type `{}`", ident) }, ); first = false; } </del> <ins> let ident = tcx.item_name(*adt_def); err.span_note( *span, &if first { format!( "`{}` contains a field of type `{}`", tcx.type_of(def.did), ident ) } else { format!("...which contains a field of type `{}`", ident) }, ); first = false; </ins> } }
Code change:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

Related discussion:
text: <ins> #[repr(transparent)] pub struct PageTableEntry { entry: u64, } #[repr(align(4096))] #[repr(C)] pub struct PageTable { entries: [PageTableEntry; 512], } </ins>
Code change:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

Related discussion:
text: <ins> // aux-build:issue-73112.rs extern crate issue_73112; fn main() { use issue_73112::PageTable; #[repr(C, packed)] struct SomeStruct { //~^ ERROR packed type cannot transitively contain a `#[repr(align)]` type [E0588] page_table: PageTable, } } </ins>
Code change:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

Related discussion:
text: <ins> error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type --> $DIR/issue-73112.rs:9:5 | LL | /     struct SomeStruct { LL | | LL | |         page_table: PageTable, LL | |     } | |_____^ | note: `PageTable` has a `#[repr(align)]` attribute --> $DIR/auxiliary/issue-73112.rs:8:1 | LL | / pub struct PageTable { LL | |     entries: [PageTableEntry; 512], LL | | } | |_^ error: aborting due to previous error For more information about this error, try `rustc --explain E0588`. </ins>
Code change:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Related discussion:
text: /// but shebang isn't a part of rust syntax. pub fn strip_shebang(input: &str) -> Option<usize> { // Shebang must start with `#!` literally, without any preceding whitespace. <del> if input.starts_with("#!") { let input_tail = &input[2..]; // Shebang must have something non-whitespace after `#!` on the first line. let first_line_tail = input_tail.lines().next()?; if first_line_tail.contains(|c| !is_whitespace(c)) { // Ok, this is a shebang but if the next non-whitespace token is `[` or maybe // a doc comment (due to `TokenKind::(Line,Block)Comment` ambiguity at lexer level), // then it may be valid Rust code, so consider it Rust code. let next_non_whitespace_token = tokenize(input_tail).map(|tok| tok.kind).find(|tok| !matches!(tok, TokenKind::Whitespace | TokenKind::LineComment | TokenKind::BlockComment { .. }) ); if next_non_whitespace_token != Some(TokenKind::OpenBracket) { // No other choice than to consider this a shebang. return Some(2 + first_line_tail.len()); } </del> <ins> // For simplicity we consider any line starting with `#!` a shebang, // regardless of restrictions put on shebangs by specific platforms. if let Some(input_tail) = input.strip_prefix("#!") { // Ok, this is a shebang but if the next non-whitespace token is `[` or maybe // a doc comment (due to `TokenKind::(Line,Block)Comment` ambiguity at lexer level), // then it may be valid Rust code, so consider it Rust code. let next_non_whitespace_token = tokenize(input_tail).map(|tok| tok.kind).find(|tok| !matches!(tok, TokenKind::Whitespace | TokenKind::LineComment | TokenKind::BlockComment { .. }) ); if next_non_whitespace_token != Some(TokenKind::OpenBracket) { // No other choice than to consider this a shebang. return Some(2 + input_tail.lines().next().unwrap_or_default().len()); </ins> } } None
Code change:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Related discussion:
text: <ins> #! // check-pass fn main() {} </ins>
Code change:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Related discussion:
text: <ins> #! // check-pass // ignore-tidy-end-whitespace fn main() {} </ins>
Code change:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Related discussion:
text: <del> #!/usr/bin/env rustx // run-pass pub fn main() { println!("Hello World"); } </del>
Code change:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

Related discussion:
text: debug!("QueryNormalizer: result = {:#?}", result); debug!("QueryNormalizer: obligations = {:#?}", obligations); self.obligations.extend(obligations); <del> Ok(result.normalized_ty) </del> <ins> let res = result.normalized_ty; // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { Ok(res.try_super_fold_with(self)?) } else { Ok(res) } </ins> } ty::Projection(data) => {
Code change:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

Related discussion:
text: <ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] trait TraitOne { const MY_NUM: usize; type MyErr: std::fmt::Debug; fn do_one_stuff(arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr>; } trait TraitTwo { fn do_two_stuff(); } impl<O: TraitOne> TraitTwo for O where [(); Self::MY_NUM]:, { fn do_two_stuff() { O::do_one_stuff([5; Self::MY_NUM]).unwrap() } } struct Blargotron; #[derive(Debug)] struct ErrTy<const N: usize>([(); N]); impl TraitOne for Blargotron { const MY_NUM: usize = 3; type MyErr = ErrTy<{ Self::MY_NUM }>; fn do_one_stuff(_arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr> { Ok(()) } } fn main() { Blargotron::do_two_stuff(); } </ins>