jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.

Related discussion:
text: let filename = "tests/parser/unclosed-delims/issue_4466.rs"; assert_parser_error(filename); } <ins> #[test] fn crate_parsing_stashed_diag() { // See also https://github.com/rust-lang/rust/issues/121450 let filename = "tests/parser/stashed-diag.rs"; assert_parser_error(filename); } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.

Related discussion:
text: <ins> #![u={static N;}] fn main() {} </ins>
Code change:
When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.

Related discussion:
text: margin: 0 auto; padding: 0 15px; font-size: 18px; <del> color: #333; </del> <ins> color: #000; </ins> line-height: 1.428571429; -webkit-box-sizing: unset; -moz-box-sizing: unset; box-sizing: unset; <ins> background: #fff; </ins> } @media (min-width: 768px) { body {
Code change:
When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.

Related discussion:
text: padding: 5px 10px; } h5, h6 { <del> color: black; </del> text-decoration: underline; }
Code change:
I tried this code: I expected to see this happen: Both and can be inlined. Instead, this happened: <details<summarycargo asm</summary</detailsWhen using , it works well. Also, when I replace with , it works well. <details<summarycargo asm</summary</details:
I think this is an llvm issue related to inlining when the target features do not match exactly and when using inline assembly: is implemented using asm and has . This seems to prevent it getting inlined into functions with additional target features. When compiling for a specific target with all these features enabled it should get inlined, but this restriction makes it very difficult to implement runtime dispatch and get performant code. I'm currently facing the same issue, and plan to replace the asm implementation with one that uses the new rust intrinsic, but this only solves the problem for masked loads/stores. The problem also exists for the implementations of , for which there is not yet a rust intrinsic.

Related discussion:
text: <del> Subproject commit 7973f3560287d750500718314a0fd4025bd8ac0e </del> <ins> Subproject commit 84f190a4abf58bbd5301c0fc831f7a96acea246f </ins>
Code change:
<!-- 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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical

Related discussion:
text: use rustc_middle::query::on_disk_cache::AbsoluteBytePos; use rustc_middle::query::on_disk_cache::{CacheDecoder, CacheEncoder, EncodedDepNodeIndex}; use rustc_middle::query::Key; <ins> use rustc_middle::ty::print::with_reduced_queries; </ins> use rustc_middle::ty::tls::{self, ImplicitCtxt}; use rustc_middle::ty::{self, TyCtxt}; use rustc_query_system::dep_graph::{DepNodeParams, HasDepContext};
Code change:
<!-- 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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical

Related discussion:
text: kind: DepKind, name: &'static str, ) -> QueryStackFrame { <ins> // If reduced queries are requested, we may be printing a query stack due // to a panic. Avoid using `default_span` and `def_kind` in that case. let reduce_queries = with_reduced_queries(); </ins> // Avoid calling queries while formatting the description let description = ty::print::with_no_queries!(do_describe(tcx, key)); let description = if tcx.sess.verbose_internals() {
Code change:
<!-- 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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical

Related discussion:
text: } else { description }; <del> let span = if kind == dep_graph::dep_kinds::def_span { </del> <ins> let span = if kind == dep_graph::dep_kinds::def_span || reduce_queries { </ins> // The `def_span` query is used to calculate `default_span`, // so exit to avoid infinite recursion. None
Code change:
<!-- 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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical

Related discussion:
text: Some(key.default_span(tcx)) }; let def_id = key.key_as_def_id(); <del> let def_kind = if kind == dep_graph::dep_kinds::def_kind { </del> <ins> let def_kind = if kind == dep_graph::dep_kinds::def_kind || reduce_queries { </ins> // Try to avoid infinite recursion. None } else {
Code change:
The documentation for these methods state respectively: However these clearly return pointers rather than references. Later on they state the following restrictions, which make sense for references but it isn't clear to me that this restriction is necessary for pointers. At the very least the change needs to be made there too.
These are nightly-only traits that aren't particularly on-track for stabilization anytime soon, but yes, changing them to be correct on those counts would be fine.
Indeed, while it's nightly only I wasn't actually going to call it from nightly, but was looking because of it's use in other stable functions, e.g. . Would make a patch, but I wasn't sure whether to leave the undefined behavior line in or whether it should be removed.
It's still UB, yeah! This is partly because it still has to fulfill the safety conditions of . Obviously, that isn't a full justification: there is the question of adding until the pointer is offset to the "last element", which would not trigger "language UB" via that implementation detail... But the library defines it as UB, which means the implementation may include code that would cause an optimizer to see that it is "impossible" for the defined-UB result to happen. And the question of whether the "surface functions" have this obligation was settled in so yes, the same conclusion applies.

Related discussion:
text: #[unstable(feature = "slice_index_methods", issue = "none")] fn get_mut(self, slice: &mut T) -> Option<&mut Self::Output>; <del> /// Returns a shared reference to the output at this location, without </del> <ins> /// Returns a pointer to the output at this location, without </ins> /// performing any bounds checking. /// Calling this method with an out-of-bounds index or a dangling `slice` pointer <del> /// is *[undefined behavior]* even if the resulting reference is not used. </del> <ins> /// is *[undefined behavior]* even if the resulting pointer is not used. </ins> /// /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html #[unstable(feature = "slice_index_methods", issue = "none")] unsafe fn get_unchecked(self, slice: *const T) -> *const Self::Output; <del> /// Returns a mutable reference to the output at this location, without </del> <ins> /// Returns a mutable pointer to the output at this location, without </ins> /// performing any bounds checking. /// Calling this method with an out-of-bounds index or a dangling `slice` pointer <del> /// is *[undefined behavior]* even if the resulting reference is not used. </del> <ins> /// is *[undefined behavior]* even if the resulting pointer is not used. </ins> /// /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html #[unstable(feature = "slice_index_methods", issue = "none")]
Code change:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

Related discussion:
text: trait_selection_closure_kind_requirement = the requirement to implement `{$trait_prefix}{$expected}` derives from here <ins> trait_selection_disallowed_positional_argument = positional format arguments are not allowed here .help = only named format arguments with the name of one of the generic types are allowed in this context </ins> trait_selection_dump_vtable_entries = vtable entries for `{$trait_ref}`: {$entries} trait_selection_empty_on_clause_in_rustc_on_unimplemented = empty `on`-clause in `#[rustc_on_unimplemented]`
Code change:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

Related discussion:
text: trait_selection_inherent_projection_normalization_overflow = overflow evaluating associated type `{$ty}` <ins> trait_selection_invalid_format_specifier = invalid format specifier .help = no format specifier are supported in this position </ins> trait_selection_invalid_on_clause_in_rustc_on_unimplemented = invalid `on`-clause in `#[rustc_on_unimplemented]` .label = invalid on-clause here
Code change:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

Related discussion:
text: trait_selection_unknown_format_parameter_for_on_unimplemented_attr = there is no parameter `{$argument_name}` on trait `{$trait_name}` .help = expect either a generic argument name or {"`{Self}`"} as format argument <ins> trait_selection_wrapped_parser_error = {$description} .label = {$label} </ins>
Code change:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

Related discussion:
text: trait_name: Symbol, } <ins> #[derive(LintDiagnostic)] #[diag(trait_selection_disallowed_positional_argument)] #[help] pub struct DisallowedPositionalArgument; #[derive(LintDiagnostic)] #[diag(trait_selection_invalid_format_specifier)] #[help] pub struct InvalidFormatSpecifier; #[derive(LintDiagnostic)] #[diag(trait_selection_wrapped_parser_error)] pub struct WrappedParserError { description: String, label: String, } </ins> impl<'tcx> OnUnimplementedDirective { fn parse( tcx: TyCtxt<'tcx>,
Code change:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

Related discussion:
text: let empty_string = String::new(); let s = self.symbol.as_str(); <del> let parser = Parser::new(s, None, None, false, ParseMode::Format); </del> <ins> let mut parser = Parser::new(s, None, None, false, ParseMode::Format); </ins> let item_context = (options.get(&sym::ItemContext)).unwrap_or(&empty_string); <del> parser </del> <ins> let constructed_message = (&mut parser) </ins> .map(|p| match p { Piece::String(s) => s.to_owned(), Piece::NextArgument(a) => match a.position {
Code change:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

Related discussion:
text: } } } <ins> Position::ArgumentImplicitlyIs(_) if self.is_diagnostic_namespace_variant => { String::from("{}") } Position::ArgumentIs(idx) if self.is_diagnostic_namespace_variant => { format!("{{{idx}}}") } </ins> _ => bug!("broken on_unimplemented {:?} - bad format arg", self.symbol), }, }) <del> .collect() </del> <ins> .collect(); // we cannot return errors from processing the format string as hard error here // as the diagnostic namespace gurantees that malformed input cannot cause an error // // if we encounter any error while processing the format string // we don't want to show the potentially half assembled formated string, // therefore we fall back to just showing the input string in this case // // The actual parser errors are emitted earlier // as lint warnings in OnUnimplementedFormatString::verify if self.is_diagnostic_namespace_variant && !parser.errors.is_empty() { String::from(s) } else { constructed_message } </ins> } }