jiebi/CodeConvo huggingface dataset:
Code change:
<ins> PRINT-ATTR INPUT (DISPLAY): fn main() { match() { | () => () } } PRINT-ATTR INPUT (DEBUG): TokenStream [ Ident { ident: "fn", span: $DIR/issue-76182-leading-vert-pat.rs:14:1: 14:3 (#0), }, Ident { ident: "main", span: $DIR/issue-76182-leading-vert-pat.rs:14:4: 14:8 (#0), }, Group { delimiter: Parenthesis, stream: TokenStream [], span: $DIR/issue-76182-leading-vert-pat.rs:14:8: 14:10 (#0), }, Group { delimiter: Brace, stream: TokenStream [ Ident { ident: "match", span: $DIR/issue-76182-leading-vert-pat.rs:15:5: 15:10 (#0), }, Group { delimiter: Parenthesis, stream: TokenStream [], span: $DIR/issue-76182-leading-vert-pat.rs:15:11: 15:13 (#0), }, Group { delimiter: Brace, stream: TokenStream [ Punct { ch: '|', spacing: Alone, span: $DIR/issue-76182-leading-vert-pat.rs:15:16: 15:17 (#0), }, Group { delimiter: Parenthesis, stream: TokenStream [], span: $DIR/issue-76182-leading-vert-pat.rs:15:18: 15:20 (#0), }, Punct { ch: '=', spacing: Joint, span: $DIR/issue-76182-leading-vert-pat.rs:15:21: 15:23 (#0), }, Punct { ch: '>', spacing: Alone, span: $DIR/issue-76182-leading-vert-pat.rs:15:21: 15:23 (#0), }, Group { delimiter: Parenthesis, stream: TokenStream [], span: $DIR/issue-76182-leading-vert-pat.rs:15:24: 15:26 (#0), }, ], span: $DIR/issue-76182-leading-vert-pat.rs:15:14: 15:28 (#0), }, ], span: $DIR/issue-76182-leading-vert-pat.rs:14:11: 16:2 (#0), }, ] </ins>

Related discussion:
text: The following code: is currently pretty-printed as: If this occurs in a macro invocation, it leads to an instance of
Extra info (but it boils down to what said): Using I get the following log: Rendered diff:
This applies to all trailing separators in theory (except that the separator is leading rather than trailing in this case), but in other cases the difference is fixed up by fuzzy comparison in .
Code change:
let mut cmd = Command::new(SHELL); cmd.current_dir(&empty_dir) .arg(sanitize_sh(&tarball.decompressed_output().join("install.sh"))) <del> .arg(format!("--prefix={}", prepare_dir(prefix))) .arg(format!("--sysconfdir={}", prepare_dir(sysconfdir))) .arg(format!("--datadir={}", prepare_dir(datadir))) .arg(format!("--docdir={}", prepare_dir(docdir))) .arg(format!("--bindir={}", prepare_dir(bindir))) .arg(format!("--libdir={}", prepare_dir(libdir))) .arg(format!("--mandir={}", prepare_dir(mandir))) </del> <ins> .arg(format!("--prefix={}", prepare_dir(&destdir_env, prefix))) .arg(format!("--sysconfdir={}", prepare_dir(&destdir_env, sysconfdir))) .arg(format!("--datadir={}", prepare_dir(&destdir_env, datadir))) .arg(format!("--docdir={}", prepare_dir(&destdir_env, docdir))) .arg(format!("--bindir={}", prepare_dir(&destdir_env, bindir))) .arg(format!("--libdir={}", prepare_dir(&destdir_env, libdir))) .arg(format!("--mandir={}", prepare_dir(&destdir_env, mandir))) </ins> .arg("--disable-ldconfig"); builder.run(&mut cmd); t!(fs::remove_dir_all(&empty_dir));

Related discussion:
text: It is cc
for backport, the PR's responsible team (T-bootstrap) also needs to label it beta-accepted. Once it has both labels, the release team will handle the actual backport.
Code change:
#[note] pub struct BuiltinInternalFeatures { pub name: Symbol, <del> #[subdiagnostic] pub note: Option<BuiltinFeatureIssueNote>, </del> } #[derive(Subdiagnostic)]

Related discussion:
text: <!-- 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 code: note the duplicate <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
feature, not a bug: we want people to be very strongly discouraged, so we say it twice.
the more repetions, the more discouraged. lang_items should go up to 10.
Maybe we should print it in an infinite loop, just to be on the save side?
This is happening on as well.
claim The source of the problem is the decorator for which is adding two to the Diagnostic instead of one. I'm trying to dig further and decipher the marco-generated decorator code here: I also noticed that the behaviour seems to differ across gates. E.g. building this: emits one note for and two notes for : Not sure what's different about these gates. I'm new to this area, so if you can provide any pointers based on the above, please do.
This program tests all the internal gates: It produces the following output: Of the 21 internal gates, only the last 6 result in duplicate notes.
These should be more, there's a file somewhere that defines all the features but I can't check it right now on mobile
I think that should be all of them. This is super weird indeed, no idea
Thanks & I found what's different about gates with duplicate notes: they all have an associated issue. Here's the full list grepped from : Notice that the second last field in the last 6 lines is unlike the rest where it is . Apparently having an associated issue causes this problem.
The root cause is the being passed on this line: Its value is for gates that have an associated issue and for others. Since already has a attribute: this results in duplicates. The solution is to always pass for internal gates.
Code change:
show_type_layout, generate_link_to_definition, call_locations, <ins> no_emit_shared, </ins> .. } = options;

Related discussion:
text: <!-- 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 rendering docs for a crate with: That puts this in the sidebar: ! In this case, and are dependencies (which I don't want to document). And is the name of one of the examples, this is a dead link.
cc - running on dependencies seems like a cargo bug, but showing them in the sidebar seems like it's an issue in rustdoc.
Thanks for the report I will take a look this week.
Ok, I have fixed the issue where examples show up in the crates list. However, I wasn't able to reproduce the issue with non-examples appearing in the crates list. Specifically, my setup was: I could not get to appear in the sidebar when using .
Thanks I tried some more things, and I think what happened is that I used it without at first, and then without clearing the folder, did it with , which apparently doesn't remove the dependencies from the sidebar. So I guess that part of the issue is about not working quite right when these artefacts already exist, and unrelated to .
Code change:
/// Strip items marked `#[doc(hidden)]` pub fn strip_hidden(krate: clean::Crate) -> plugins::PluginResult { <del> struct Stripper; impl fold::DocFolder for Stripper { fn fold_item(&mut self, i: Item) -> Option<Item> { for attr in i.attrs.iter() { match attr { &clean::List(~"doc", ref l) => { for innerattr in l.iter() { match innerattr { &clean::Word(ref s) if "hidden" == *s => { debug!("found one in strip_hidden; removing"); return None; }, _ => (), </del> <ins> let mut stripped = HashSet::new(); // strip all #[doc(hidden)] items let krate = { struct Stripper<'a> { stripped: &'a mut HashSet<ast::NodeId> }; impl<'a> fold::DocFolder for Stripper<'a> { fn fold_item(&mut self, i: Item) -> Option<Item> { for attr in i.attrs.iter() { match attr { &clean::List(~"doc", ref l) => { for innerattr in l.iter() { match innerattr { &clean::Word(ref s) if "hidden" == *s => { debug!("found one in strip_hidden; removing"); self.stripped.insert(i.id); return None; }, _ => (), } </ins> } <ins> }, _ => () } } self.fold_item_recur(i) } } let mut stripper = Stripper{ stripped: &mut stripped }; stripper.fold_crate(krate) }; // strip any traits implemented on stripped items let krate = { struct ImplStripper<'a> { stripped: &'a mut HashSet<ast::NodeId> }; impl<'a> fold::DocFolder for ImplStripper<'a> { fn fold_item(&mut self, i: Item) -> Option<Item> { match i.inner { clean::ImplItem(clean::Impl{ for_: clean::ResolvedPath{ id: for_id, .. }, .. }) => { if self.stripped.contains(&for_id) { return None; </ins> } <del> }, _ => () </del> <ins> } _ => {} </ins> } <ins> self.fold_item_recur(i) </ins> } <del> self.fold_item_recur(i) </del> } <del> } let mut stripper = Stripper; let krate = stripper.fold_crate(krate); </del> <ins> let mut stripper = ImplStripper{ stripped: &mut stripped }; stripper.fold_crate(krate) }; </ins> (krate, None) }

Related discussion:
text: Trying to search for anything on results in a Javascript error: on line 313 of I'm on Chrome 30.0.1599.101 if that matters.
Weirdly, search results still appear if I search for most things, but not for anything starting with "sle" like "sleep".
This appears to be dying because of the method defined in . This shouldn't be showing up in the search because the entire module should be pruned as a result of it being private. This warrants more investigation...
Update: seems like it's not for "any" keyword as the OP states; for example or don't trigger any error for me. does for instance.
doesn't work either.
Happens to me too.
, , , , , , , and (and all shortened forms e.g. , ) don't work for me, but does work (i.e. shows results). The error I'm getting (on Firefox Nightly 29.0a1) is .
The error happens when a trait is implemented on a type that is pruned by one of the passes ( or ). The type was pruned but the implementation was not, so the search index included a method that referenced a missing type. fixes this.
Code change:
self_expr: &'tcx hir::Expr<'tcx>, call_expr: &'tcx hir::Expr<'tcx>, ) -> ConfirmContext<'a, 'tcx> { <del> ConfirmContext { fcx, span, self_expr, call_expr } </del> <ins> ConfirmContext { fcx, span, self_expr, call_expr, skip_record_for_diagnostics: false } </ins> } fn confirm(

Related discussion:
text: <!-- 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. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
// can just use the tcx as the typer. // // FIXME(stage0): the :'t here is probably only important for stage0 <del> pub struct ExprUseVisitor<'d, 't, 'a: 't, 'tcx:'a+'d+'t> { </del> <ins> pub struct ExprUseVisitor<'d, 't, 'a: 't, 'tcx:'a+'d> { </ins> typer: &'t infer::InferCtxt<'a, 'tcx>, mc: mc::MemCategorizationContext<'t, 'a, 'tcx>, delegate: &'d mut Delegate<'tcx>,

Related discussion:
text: When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata
Code change:
#[rustc_on_unimplemented = "the type {Self} contains interior mutability  and a reference may not be safely transferrable  across a recover boundary"] <del> pub trait NoUnsafeCell {} </del> <ins> pub trait RefRecoverSafe {} </ins> /// A simple wrapper around a type to assert that it is panic safe. ///

Related discussion:
text: Test Case 1: Test Case 2: Both produce errors like this: CC
Hm, so the first case here should work (e.g. should subvert basically everything), although the second case is correct in yielding an error (albeit not a very good one)
Is the second case not allowed then? 's documentation suggests that manually implementing it is okay to do: I figured only existed to wrap types which you couldn't yourself, but for which you can ensure their invariants are upheld across the boundary. And what about moving values into the closure? can't be unwrapped, at least not currently.
Oh wait sorry I misread your second example, I failed to notice the manual ! This is basically a case where closure captures are coming into play. The closures aren't annotated with , so outer variables are captured by-reference which means that the actual types being tested against the trait here are and . In the first case that should be handled by , but the second is legitimately indicating that it's not a recover-safe type (b/c the reference is different than the by-value). You should be able to get around this via either plus or via . Certainly an interesting interaction going on here though. One would likely expect that if isn't recover safe that would fix the problem but it's likely what you really need to do is due to the way closures largely work.
There's , why not ? Coherence?
Nah unfortunately that'd defeat the purpose of the distinction. The type is itself recover safe, it's just that's not (so the distinction need to be there)
It's unfortunate that fails due to coherence or something like that:
Hm interesting, I guess yeah you'll be forced to move the reference inside the wrapper rather than having a reference to the wrapper
Is it possible to implement then? My use case can contain and friends but I'm guaranteeing that they're unobservable in user code after recovery because I immediately re-panic after escaping the FFI stack.
I guess I can just use once it's fixed :stuckouttongue:. I see your PR has been accepted so I'll look forward to trying it on tonight's nightly. When do the buildbots fire?
Yeah currently you can implement (being renamed to ) I believe (although I can't say I've tried). For now though yeah I'd recommend just using plus closures.
Code change:
#[rustc_on_unimplemented = "the type {Self} contains interior mutability  and a reference may not be safely transferrable  across a recover boundary"] <del> pub trait NoUnsafeCell {} </del> <ins> pub trait RefRecoverSafe {} </ins> /// A simple wrapper around a type to assert that it is panic safe. ///

Related discussion:
text: The PR is in but'll take a few hours at least to land.
the problem with moving at this point in time is that I call in different branches of a but I pass the same closed-over value to it; I can't do the branch in the closure because I need to do some FFI cleanup afterwards regardless of whether a panic happened or not (which also requires the closed-over value). It would help if derived and/or so I could reuse it without constructing a new value for each arm, but that would probably require some discussion because I don't know if it's safe or not. I'll probably just implement and fix the name after your PR drops. A quick check confirms that it works just fine. Thanks anyways!
Oh yeah we could totally add more traits like and to , there shouldn't be any safety concerns there.
Updating code to modern functions and traits in makes this compile, so I'm going to close.
Code change:
impl FromStr for Ipv4Addr { type Err = AddrParseError; fn from_str(s: &str) -> Result<Ipv4Addr, AddrParseError> { <del> Parser::new(s).parse_with(|p| p.read_ipv4_addr()) </del> <ins> // don't try to parse if too long if s.len() > 15 { Err(AddrParseError(())) } else { Parser::new(s).parse_with(|p| p.read_ipv4_addr()) } </ins> } }

Related discussion:
text: According to the , "The four octets are in decimal notation, divided by . (this is called 'dot-decimal notation'). Notably, octal numbers and hexadecimal numbers are not allowed per IETF RFC 6943"; however the parsing of the violates the "strict" form mentioned in —this form is what prohibits octal and hexadecimal numbers—meanwhile the conforms to it. IETF RFC 6943 Section 3.1.1. states: If the af argument of inetpton() is AFINET, the src string shall be in the standard IPv4 dotted-decimal form: where "ddd" is a one to three digit decimal number between 0 and The inetpton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inetaddr() accepts). As shown above, inetpton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AINUMERICHOST flag is passed to it. I tried this code: I expected to see this happen: both s not causing a panic since the first has an octet represented by more than three base-10 numbers despite the requirement per RFC 6943 stating each octet be a "one to three digit decimal number". The second is valid per RFC 6943 since it is a string of exactly 4 octets separated by where each octet is a "one to three digit decimal number". Instead, this happened: Both lines cause a panic. : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I believe that the second input () is not valid, since the spec explicitly says that octal numbers are disallowed, and is an octal number in the loose form. The example in the RFC for an octal number is , which parses to if you use octal, but if you use decimal. If you instead have it parse it always as , that means that bad things can happen, such as different tools interpreting as different things.
Code change:
impl FromStr for Ipv4Addr { type Err = AddrParseError; fn from_str(s: &str) -> Result<Ipv4Addr, AddrParseError> { <del> Parser::new(s).parse_with(|p| p.read_ipv4_addr()) </del> <ins> // don't try to parse if too long if s.len() > 15 { Err(AddrParseError(())) } else { Parser::new(s).parse_with(|p| p.read_ipv4_addr()) } </ins> } }

Related discussion:
text: If you read the source code where the ipv4 address is parsed, it specifically disallows that: Regarding , the documentation only says that the disallowing of hexadecimal and octal numbers are according to IETF RFC 6943, and does not say anything about only allowing three digits. Also, four or more zeroes are an edge case, and thus the only numbers that can be parsed there with more than three digits, due to the disallowing of octal numbers apart from .
From the :
I'm confused by these comments. Padded zeros is not unique to the base-8 numeral system. Base-2, Base-3, etc. all have the property of having an infinite number of padded zeros with the convention being to truncate them all. After all is also valid in base-8, base-9, etc. The documentation is quite clear that the octets are to be interpreted in base-10 though, so this problem of how to interpret the octets is solved. Consequently the last octet in is interpreted as 1 in base-10 for the same reason the first octet in is interpreted as 127 in base-10 and not some other value (e.g., 87 in base-10) namely because the documentation says so. After all objecting to on the grounds that the last octet could be in base-8—again, all of the octets there could be in base-8—doesn't apply to the fact that is also rejected by the parsing algorithm since clearly each of those octets are not in base-8 since is not a symbol in the base-8 numeral system. This is of course nothing more than a consequence of incorrectly assuming padded 0s means base-8. The inconsistent treatment of 0 (in base-10) is also a consequence of this incorrect assumption. Why is 0 (in base-10) allowed to be represented by one or more s, but 1 (in base-10) cannot have padded s? There is nothing special about the syntactic representation of 0 (in base-10) that warrants this inconsistent treatment. To me the solution is clear: more strictly follow IETF RFC 6943 and enforce that each octet be one-to-three digits in length.
Code change:
impl FromStr for Ipv4Addr { type Err = AddrParseError; fn from_str(s: &str) -> Result<Ipv4Addr, AddrParseError> { <del> Parser::new(s).parse_with(|p| p.read_ipv4_addr()) </del> <ins> // don't try to parse if too long if s.len() > 15 { Err(AddrParseError(())) } else { Parser::new(s).parse_with(|p| p.read_ipv4_addr()) } </ins> } }

Related discussion:
text: One could even follow a stricter format and require that there be no padded s at all—since the RFC doesn't actually specify that. This would then lead to consistent behavior (that's also more easily predictable since it follows a well-established convention) in that both and will either be accepted (since they both follow RFC 6943) or rejected (if a stricter form is required that requires the minimal number of digits necessary to represent each octet).
This is not an incorrect assumption, as octal numbers in the loose format are specified by the number having a leading zero. (See for the PR that banned octal numbers) This is an implementation detail in the way that it checks for leading zeroes: it checks if the number starts with a zero and rejects it if the resultant parsed number is not zero.
So we are re-defining how mathematics defines numeral systems? Saying that is in base-8 (i.e., octal) because of the leading makes no sense since none of those symbols except exist in that system. Rust certainly doesn't treat the in base-8 here: . Also the documentation clearly states that each octet is in "decimal notation". Suddenly treating the octet as base-8 is a clear contradiction to the documentation.
Using leading zeros to designate octal literals is a fairly common convention. In other languages like JS and C, . Rust doesn't have that as an octal prefix because it is confusing. When using leading zeros to indicate octal numbers, isn't a valid number at all (in the same way that isn't a valid base-10 number).
So it sounds like the documentation needs to be modified. It is confusing (because it is contradictory to reality) to say that each octet is in decimal notation when the actual implementation requires each octet to be either base-10 or base-8 where the latter is assumed when there are leading s and the value is not 0—at which point any positive-integer amount of s are allowed—and furthermore error when any octet is interpreted as base-8. Seems much easier to both document and comprehend to simply require at most 3 decimal digits for each octet and either forbid leading s (including for the integer 0) or allow leading s (including ).
"The actual implementation" is relevant only insofar as its behavior is externally observable.