jiebi/CodeConvo huggingface dataset:
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: 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:
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: 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:
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 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:
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: 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:
_ => {} } } <del> if arg.layout.is_aggregate() && (int_regs < needed_int || sse_regs < needed_sse) { cls_or_mem = Err(Memory); </del> <ins> match (int_regs.checked_sub(needed_int), sse_regs.checked_sub(needed_sse)) { (Some(left_int), Some(left_sse)) => { int_regs = left_int; sse_regs = left_sse; } _ => { // Not enough registers for this argument, so it will be // passed on the stack, but we only mark aggregates // explicitly as indirect `byval` arguments, as LLVM will // automatically put immediates on the stack itself. if arg.layout.is_aggregate() { cls_or_mem = Err(Memory); } } </ins> } } }

Related discussion:
text: We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).
Code change:
_ => {} } } <del> if arg.layout.is_aggregate() && (int_regs < needed_int || sse_regs < needed_sse) { cls_or_mem = Err(Memory); </del> <ins> match (int_regs.checked_sub(needed_int), sse_regs.checked_sub(needed_sse)) { (Some(left_int), Some(left_sse)) => { int_regs = left_int; sse_regs = left_sse; } _ => { // Not enough registers for this argument, so it will be // passed on the stack, but we only mark aggregates // explicitly as indirect `byval` arguments, as LLVM will // automatically put immediates on the stack itself. if arg.layout.is_aggregate() { cls_or_mem = Err(Memory); } } </ins> } } }

Related discussion:
text: Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway
Code change:
<ins> fn foo() { match 0 { _ => {} } if foo } } //~ ERROR unexpected closing delimiter: `}` fn main() {} </ins>

Related discussion:
text: See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).
Code change:
/// use std::sync::Arc; /// use std::task::{Context, Poll, Wake}; /// use std::thread::{self, Thread}; <ins> /// use core::pin::pin; </ins> /// /// /// A waker that wakes up the current thread when called. /// struct ThreadWaker(Thread);

Related discussion:
text: The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks
Code change:
<ins> // check-pass // revisions: legacy v0 //[legacy]compile-flags: -Z symbol-mangling-version=legacy --crate-type=lib //[v0]compile-flags: -Z symbol-mangling-version=v0 --crate-type=lib #![feature(min_const_generics)] pub struct Bar<const F: bool>; impl Bar<true> { pub fn foo() {} } impl<const F: bool> Bar<F> { pub fn bar() {} } fn main() {} </ins>

Related discussion:
text: Command was with the following <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
And yes, was enough to get the build to finish, in case there were any questions as to whether that was the difference.
This is the first PR that fails with the error described in I do not know if the fault is here or in the symbol mangling but it as I understand it that function that is called is only used for the the size of an array and it feels strange that it shall be a bool -- it seems pretty clear the bug is in the symbol mangling rather than with , because it's not adding anything out of the "ordinary" Rust code. That said, it's likely that the const generic could be replaced to avoid the error perhaps.
Yeah, isn't this "just" an instance of new symbol mangling not being compatible with const generics?
was to tired that night when I hade bisected the rust build and this hade nothing to do with arrays that I was writing. was possible to avoid the bisect all together if I only hade looked trough all of the log. it is saying that it is eg. that fails so it is the bool in the path that is triggering the fault in symbol mangling. according to only unsigned integers is handled and the rest is left for "future const-generics work" shall this be marked with some const-generic label? right now it is only bool that also needs to be handled for rustc to compile but do not know how to go forward
seems like there is a issue for adding mangling support here so this will probably be fixed when that issue is fixed.
Code change:
} #[cfg(any( <del> all(not(target_arch = "aarch64"), not(target_arch = "powerpc"), not(target_arch = "x86_64")), </del> <ins> all( not(target_arch = "aarch64"), not(target_arch = "powerpc"), not(target_arch = "s390x"), not(target_arch = "x86_64") ), </ins> all(target_arch = "aarch64", any(target_os = "macos", target_os = "ios")), target_family = "wasm", target_arch = "asmjs",

Related discussion:
text: fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.
Code change:
<ins> use std::marker::PhantomData; struct Foo<'a, 'b, T>(PhantomData<(&'a (), &'b (), T)>) where Foo<'short, 'out, T>: Convert<'a, 'b>; //~^ ERROR mismatched types //~^^ ERROR mismatched types //~^^^ ERROR use of undeclared lifetime name //~| ERROR use of undeclared lifetime name `'out` trait Convert<'a, 'b>: Sized { fn cast(&'a self) -> &'b Self; } impl<'long: 'short, 'short, T> Convert<'long, 'b> for Foo<'short, 'out, T> { //~^ ERROR use of undeclared lifetime name //~^^ ERROR use of undeclared lifetime name `'out` //~| ERROR cannot infer an appropriate lifetime for lifetime parameter fn cast(&'long self) -> &'short Foo<'short, 'out, T> { //~^ ERROR use of undeclared lifetime name //~| ERROR cannot infer an appropriate lifetime for lifetime parameter self } } fn badboi<'in_, 'out, T>(x: Foo<'in_, 'out, T>, sadness: &'in_ Foo<'short, 'out, T>) -> &'out T { //~^ ERROR use of undeclared lifetime name //~^^ ERROR incompatible lifetime on type //~| ERROR `x` has lifetime `'in_` but it needs to satisfy a `'static` lifetime requirement sadness.cast() } fn main() {} </ins>

Related discussion:
text: [ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :
Code change:
/// assert!(weak.upgrade().is_none()); /// ``` /// <del> /// Unaligned values cannot be dropped in place, they must be copied to an aligned /// location first: /// ``` /// use std::ptr; /// use std::mem::{self, MaybeUninit}; /// /// unsafe fn drop_after_copy<T>(to_drop: *mut T) { ///     let mut copy: MaybeUninit<T> = MaybeUninit::uninit(); ///     ptr::copy(to_drop, copy.as_mut_ptr(), 1); ///     drop(copy.assume_init()); /// } /// /// #[repr(packed, C)] /// struct Packed { ///     _padding: u8, ///     unaligned: Vec<i32>, /// } /// /// let mut p = Packed { _padding: 0, unaligned: vec![42] }; /// unsafe { ///     drop_after_copy(&mut p.unaligned as *mut _); ///     mem::forget(p); /// } /// ``` /// </del> /// Notice that the compiler performs this copy automatically when dropping packed structs, /// i.e., you do not usually have to worry about such issues unless you call `drop_in_place` /// manually.

Related discussion:
text: The docs for  state: And include an example which uses to copy the value from an unaligned pointer into an aligned one. However, the docs for  state: Either the docs for are wrong, and does not need to be aligned, or the example for invokes UB and should be updated to use
cc (It's also notable that the example in is wrong when it uses as is seen if you move the statement out of the block; we should fix that ASAP)
Good catch! What we'd really want is , I think... we don't want an intermediate value on the stack. Feel free to suggest code that we can use instead. We have several doctests that need They have been there since 1.0 and longer, probably. But nobody listens to me when I say that there is existing code that we need to support ASAP.
The example given is just using to put it on the stack anyway. If you're having to copy the value at all, there's really no reason to use at that point, since the only reason to use it instead of is to avoid the copy (which is optimized out in release mode anyway). I think we can probably just remove the unaligned example entirely and change the documentation to read: I think we should probably mention the caveat WRT the optimizer eliminating the copy (or can it even do that in this case? The docs mention that the drop glue generated for packed structs does this copy automatically, I'm curious if it's doing so in a way that is UB or if the copy is just the price you have to pay here. It's also worth noting that there's no way to an unsized value through an unaligned pointer, but I'm not sure that's worth bringing up at all in the docs, since there's no reasonable way to actually get that pointer in the first place.
Oh, good point. Yeah then you can basically just make it , right? I wonder why / ever got used here? Well but wouldn't it make sense for that text to come with an example? It cannot, because then it would be introducing alignment errors. Uh... yeah. With it could work. Doesn't seem like a reasonable thing to have either way?
Presumably because they wanted the example to continue to use Sure, we could -- it just wouldn't ever call the function being documented.
Code change:
/// assert!(weak.upgrade().is_none()); /// ``` /// <del> /// Unaligned values cannot be dropped in place, they must be copied to an aligned /// location first: /// ``` /// use std::ptr; /// use std::mem::{self, MaybeUninit}; /// /// unsafe fn drop_after_copy<T>(to_drop: *mut T) { ///     let mut copy: MaybeUninit<T> = MaybeUninit::uninit(); ///     ptr::copy(to_drop, copy.as_mut_ptr(), 1); ///     drop(copy.assume_init()); /// } /// /// #[repr(packed, C)] /// struct Packed { ///     _padding: u8, ///     unaligned: Vec<i32>, /// } /// /// let mut p = Packed { _padding: 0, unaligned: vec![42] }; /// unsafe { ///     drop_after_copy(&mut p.unaligned as *mut _); ///     mem::forget(p); /// } /// ``` /// </del> /// Notice that the compiler performs this copy automatically when dropping packed structs, /// i.e., you do not usually have to worry about such issues unless you call `drop_in_place` /// manually.

Related discussion:
text: Yes, it's just unrelated to dropping unaligned pointers since the only place you can reasonably copy them to is the stack. Unless you happen to already have an valid pointer of the proper size and alignment sitting around
I'm not actually sure unalgined DSTs are so unreasonable. For example, is only stopped by this rule: Which could be solved if we had e.g. a way to express "does not have drop glue" as a bound ( doesn't work for obvious reasons). In any case, I think "copy unaligned" functions make sense but we might want to consider multiple variants for src only / dest only / both unaligned. This can be expressed in LLVM IR though in a brief test I couldn't demonstrate that it currently makes a codegen difference (but I could only try on x86_64, where alignment rarely matters for codegen).
:rofl: fair. I guess all of this is basically saying an in-place drop of unaligned data is just not possible. Do an "out-of-place" drop instead.
Actually looks like the use of an unaligned pointer in the doctest just caused to fail to land. ;)
Proposed fix at