jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> if digit_count == 0 { None } else { Some(result) } </del> <ins> if digit_count == 0 { None } else if !allow_zero_prefix && has_leading_zero && digit_count > 1 { None } else { Some(result) } </ins> }) }

Related discussion:
text: And -- correct me if I'm wrong -- in every case where the function succeeds, it (behaves as if it) interprets all digits in decimal, right? So I'd say it is correct to say that everything is "in decimal notation". The only weird bit is that is accepted, but is not. This is strange, but not in contradiction with saying things are "in decimal notation".
When the documentation says the "four octets are in decimal notation", that is effectively a definition which in turn can be phrased as a logical biconditional. In this case, the logical biconditional I formed in my head was something like: "a will be parsed into an iff it is a sequence of exactly 4 base-10 numbers delimited by a ". Only one of those directions is true: if an is produced from parsing a , then the was a sequence of exactly 4 base-10 numbers delimited by a . The other direction, which is observable via a parsing failure, is not true as can be seen with something like . That is a sequence of exactly 4 base-10 numbers delimited by a , but it leads to a parsing failure. As was discovered in the discussion , it sounds like "decimal notation" as used in the documentation is not what it has meant my entire life nor what it means in a lot of areas in Rust. Specifically, any number that has leading s is not a base-10 number but in fact a base-8 number. With this modified definition of "decimal"; then my counterexample, , is in fact not a counterexample since each of those octets are not in "decimal" notation but in fact base-8. Even more perplexing as stated by is that "a lone 0 is technically octal as well in C, not that it matters" which means the definition of "decimal" used in the documentation is neither the mathematical definition nor the C definition—since something like is successfully parsed despite each of those octets being in base-8 per the C definition.
That's true in C. (Specifically, it is how C converts series of digits to numbers. "Numbers" don't have leading 0s, numbers are elements of the set of integers. The representation of a number as a string of digits can have leading 0s.
Code change:
} } <del> if digit_count == 0 { None } else { Some(result) } </del> <ins> if digit_count == 0 { None } else if !allow_zero_prefix && has_leading_zero && digit_count > 1 { None } else { Some(result) } </ins> }) }

Related discussion:
text: At least that's how I think the term is usually used when one needs to be precise about series of digits vs. the thing they represent.) However, it's not true for this function. Any number that has leading 0s is rejected by this function. This fact about C was brought up only to explain why leading 0s are rejected. No base-8 occurs anywhere in the behavior of this function. If you disagree, please show an input-output pair for this function which demonstrates that base 8 is used. (The code inside the function doesn't matter, of course. Only its observable behavior does.) I really don't understand why you keep insisting that this function has anything to do with base 8. I think it might be because of some quirk in how it is implemented, but unobservable implementation details are irrelevant. As a mathematician you should be even more used to this than most programmers, since the usual way of defining mathematical functions consists entirely of input-output pairs, there is not even such a thing as an "implementation"... but I am digressing. ;) Even mathematically speaking, the sequence of digits "0" represents the same number in any base system. So, in a very precise formal sense, "not that it matters" is accurate. A base is just a way to convert a series of digits into a number, and for series of digits consisting only of 0s, the result is always the same. The definition of "decimal" used in the documentation exactly matches the mathematical definition. The documentation just fails to mention that there is an additional restriction, namely that no leading 0s are accepted (except if all digits of an octet are 0). However, it remains the case that if an input is accepted by this function, then all octets are interpreted as decimal -- and moreover, all decimal representations without leading 0s are accepted by this function.
Saying a definition matches exactly with another definition before subsequently changing the definition by adding other restrictions does not make sense to me. Does the definition of an even integer "match exactly" with the definition of an integer? No. Adding or removing restrictions to a definition changes the definition. So the fact that leading s is not allowed means we are not talking about mathematical base-10.
Code change:
} } <del> if digit_count == 0 { None } else { Some(result) } </del> <ins> if digit_count == 0 { None } else if !allow_zero_prefix && has_leading_zero && digit_count > 1 { None } else { Some(result) } </ins> }) }

Related discussion:
text: If I define a function that takes an integer and it errors any time the integer is not even; however the documentation of that function makes no mention of that seems very problematic. I would not defend such documentation by saying "my definition of integer matches exactly with the definition of the mathematical definition of an integer except I also require the integer to be divisible by 2". My documentation should very clearly define what I mean by "integer", or better, simply state "even integer".
Okay, I guess I should have said that it is strictly a restriction of the mathematical definition (a subset, if you take the graph view of a function). But it doesn't disagree on any inputs where it is defined. Your talking about base 8 makes it sound like sometimes it is not matching the base 10 function even when it does produce a result (but matches the base 8 function instead), and it took a quite a lot of time to realize that is not what happens. Moreover, the subset still contains the full graph of the inverse of the full "base 10" function where you always pick the shortest representation (i.e., the most common "serialization" function of numbers into base 10 representation). So unlike your "even" example it is a pretty reasonable parsing function still. There are only some "non-canonical" representations being rejected.
Well, I think we are talking in circles at this point honestly, lol. While I would agree my example is a more extreme example of documentation failure since conflating the definition of "even integer" with "integer" is more absurd than conflating the definition of "base-10 in the shortest representation (with the exception of 0 which is allowed any non-negative integer amount of leading 0s)" with "base-10", both examples suffer from the fact that additional failures occur than otherwise would occur based on the exact definition of the term that is used (in my example "integer" and in this example "decimal"). For me, as I mentioned in the other discussion, this really is not me being "pedantic". I wrote code based on the documentation that ended being invalid since I (mis-)interpreted "decimal" to be more general than what it actually means in this context.
Code change:
} } <del> if digit_count == 0 { None } else { Some(result) } </del> <ins> if digit_count == 0 { None } else if !allow_zero_prefix && has_leading_zero && digit_count > 1 { None } else { Some(result) } </ins> }) }

Related discussion:
text: Ideally, in my opinion at least, that should not happen especially since it is not that much additional effort to more properly document what certain terms mean even if that means just adding one or two more examples highlighting parsing failures (or successes) that one (like myself) would not expect.
We already agree that the docs need to be improved. :) The rest of this discussion is then mostly philosophical and not going to lead to a productive outcome, so maybe we better stop it. ;)
Code change:
lpFilePart: *mut LPWSTR, ) -> DWORD; pub fn GetFileAttributesW(lpFileName: LPCWSTR) -> DWORD; <ins> pub fn MultiByteToWideChar( CodePage: UINT, dwFlags: DWORD, lpMultiByteStr: LPCCH, cbMultiByte: c_int, lpWideCharStr: LPWSTR, cchWideChar: c_int, ) -> c_int; pub fn WideCharToMultiByte( CodePage: UINT, dwFlags: DWORD, lpWideCharStr: LPCWCH, cchWideChar: c_int, lpMultiByteStr: LPSTR, cbMultiByte: c_int, lpDefaultChar: LPCCH, lpUsedDefaultChar: LPBOOL, ) -> c_int; </ins> } #[link(name = "ws2_32")]

Related discussion:
text: (and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
Code change:
lpFilePart: *mut LPWSTR, ) -> DWORD; pub fn GetFileAttributesW(lpFileName: LPCWSTR) -> DWORD; <ins> pub fn MultiByteToWideChar( CodePage: UINT, dwFlags: DWORD, lpMultiByteStr: LPCCH, cbMultiByte: c_int, lpWideCharStr: LPWSTR, cchWideChar: c_int, ) -> c_int; pub fn WideCharToMultiByte( CodePage: UINT, dwFlags: DWORD, lpWideCharStr: LPCWCH, cchWideChar: c_int, lpMultiByteStr: LPSTR, cbMultiByte: c_int, lpDefaultChar: LPCCH, lpUsedDefaultChar: LPBOOL, ) -> c_int; </ins> } #[link(name = "ws2_32")]

Related discussion:
text: I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole
Code change:
let mut result = match self.source_map().span_to_unmapped_path(callsite) { FileName::Real(path) => path, FileName::DocTest(path, _) => path, <del> other => panic!("cannot resolve relative path in non-file source `{}`", other), </del> <ins> other => return Err(self.struct_span_err( span, &format!("cannot resolve relative path in non-file source `{}`", other), )), </ins> }; result.pop(); result.push(path); <del> result </del> <ins> Ok(result) </ins> } else { <del> path </del> <ins> Ok(path) </ins> } } }

Related discussion:
text: to reproduce the fault this can be used: will result in this ICE: thread 'rustc' panicked at 'cannot resolve relative path in non-file source ', note: Run with RUSTBACKTRACE=1 environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.36.0 ( 2019-07-03) running on x86_64-unknown-linux-gnu the question is what is the path that shall be used when the code is from stdin maybe some temp file name in the currrent working dir.
This ICE also occurs when using and , which makes sense as they use the same mechanism under the hood (, , meaning it also .
While poking at this I also noticed that items are silently ignored, and filed .
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { extern crate libc; //~ ERROR use of unstable use libc::*; //~ ERROR unresolved import } </ins>

Related discussion:
text: This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { extern crate libc; //~ ERROR use of unstable use libc::*; //~ ERROR unresolved import } </ins>

Related discussion:
text: Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { extern crate libc; //~ ERROR use of unstable use libc::*; //~ ERROR unresolved import } </ins>

Related discussion:
text: Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details
Code change:
<ins> // check-pass // edition:2021 #![deny(opaque_hidden_inferred_bound)] trait Repository /* : ?Sized */ { async fn new() -> Self; } struct MyRepository {} impl Repository for MyRepository { async fn new() -> Self { todo!() } } fn main() {} </ins>

Related discussion:
text: When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- 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. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with
Code change:
<ins> const fn f() -> usize { //~^ ERROR mismatched types const FIELD: usize = loop { 0 //~^ ERROR mismatched types }; } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)', 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [checkwellformed] checking that is well-formed --
fyi
Code change:
) -> Option<Discr<'tcx>> { let param_env = ParamEnv::empty(); let repr_type = self.repr.discr_type(); <del> let bit_size = layout::Integer::from_attr(tcx, repr_type).size().bits(); </del> let substs = Substs::identity_for_item(tcx.global_tcx(), expr_did); let instance = ty::Instance::new(expr_did, substs); let cid = GlobalId {

Related discussion:
text: I was trying to build which pulls in pango 0.1.3 as dependency . While building pango, rustc segfaults  meta: Crash happens in So apparently const eval produces a discriminant that doesn't match any variant's discriminant. more concretely, it happens during a match on which is the only discriminant with as its value.
weird, I am still getting the panic with todays nightly :(
Same backtrace? We do have a regression test for this exact issue
Yeah, backtrace is identical except for the rustc version string in the ICE notes. :/
Fix confirmed, thanks!
Code change:
<ins> // Test that existential types are allowed to contain late-bound regions. // compile-pass // edition:2018 #![feature(async_await, existential_type)] use std::future::Future; pub existential type Func: Sized; // Late bound region should be allowed to escape the function, since it's bound // in the type. fn null_function_ptr() -> Func { None::<for<'a> fn(&'a ())> } async fn async_nop(_: &u8) {} pub existential type ServeFut: Future<Output=()>; // Late bound regions occur in the generator witness type here. fn serve() -> ServeFut { async move { let x = 5; async_nop(&x).await } } fn main() {} </ins>

Related discussion:
text: cc
Am I correct in assuming that this should not compile, but report an error about returning a reference to the local variable ? Or is the self-borrowing generator part what makes this work? so the is part of the generator struct and the is the yielded thing? I'll try pretty printing to the expanded HIR, since I'm not sure what's going on there
Expanded version:
No, this should definitely compile. isn't yielded, but yes, it's a local variable inside the generator (that references another local variable in the generator).
Hmm, so because the generator contains references, it has lifetimes, but these lifetimes actually refer to the generator again? Do we have a special kind of lifetime that we use for this? We should just ignore those generator lifetimes for existential types.
There's no special lifetime afaik (cc
We should ignore all bound regions. Function pointers have the same issue:
Code change:
let is_anonymous = item.ident.name == kw::Empty; let repr = if is_anonymous { <del> tcx.adt_def(tcx.local_parent(def_id)).repr() </del> <ins> let parent = tcx.local_parent(def_id); if let Node::Item(item) = tcx.hir_node_by_def_id(parent) && item.is_struct_or_union() { tcx.adt_def(parent).repr() } else { tcx.dcx().span_delayed_bug(item.span, "anonymous field inside non struct/union"); ty::ReprOptions::default() } </ins> } else { tcx.repr_options_of_def(def_id.to_def_id()) };

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected ADT to be an item', 'error: internal compiler error: expected ADT to be an item' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [adtdef] computing ADT definition for [adtdef] computing ADT definition for [typeof] computing type of [inferredoutlivescrate] computing the inferred outlives predicates for items in this crate [inferredoutlivesof] computing inferred outlives predicates of [predicatesdefinedon] computing predicates of [predicatesof] computing predicates of [collectmoditemtypes] collecting item types in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Oh, seems that more checks are needed to prevent unnamed fields from occurring in enums.
claim
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Trait<'a> { type A; type B; } fn foo<'a, T: Trait<'a>>(value: T::A) { let new: T::B = unsafe { std::mem::transmute(value) }; //~^ ERROR: cannot transmute to or from a type that contains type parameters in its interior [E0139] } fn main() { } </ins>

Related discussion:
text: Minimised example: Both the and the fail in the same way, with an ICE: Adding bounds to and on the trait or in the fn’s where clause doesn’t fix it, but changing to does fix it. (In the particular case that I was dealing with, the lifetime could_ be changed to where this was a problem, but it would only have taken a slight variation of it for me to be in a situation where I needed a non- implementation. There were, of course, other arguments which were using the .) The whole thing around there seems a bit fragile and I’m not quite sure what’s supposed to work and what’s not; if we just take an and transmute it to , for example, we get “error: cannot transmute to or from a type that contains type parameters in its interior [E0139]”. Anyway, an ICE is always a bug, so here’s the report!
No longer repros. compiles now. Fails with: But no ICE.