jiebi/CodeConvo huggingface dataset:
Code change:
#[stable(feature = "unicode_version", since = "1.45.0")] pub use crate::unicode::UNICODE_VERSION; <ins> // perma-unstable re-exports #[unstable(feature = "char_internals", reason = "exposed only for libstd", issue = "none")] pub use self::methods::encode_utf16_raw; #[unstable(feature = "char_internals", reason = "exposed only for libstd", issue = "none")] pub use self::methods::encode_utf8_raw; </ins> use crate::fmt::{self, Write}; use crate::iter::FusedIterator;

Related discussion:
text: The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.
Code change:
))] mod imp { use super::Handler; <ins> use crate::io; </ins> use crate::mem; use crate::ptr;

Related discussion:
text: There is too little confidence in this mistake, why not return to errno. The mmap interface provides the errno, such as the ENOMEM and SIGSEGV interfaces. panic!("failed to allocate an alternative stack")
!
Please try again your code latest nightly Rust version. Also could you paste the ICE backtrace? label E-needs-mcve I-ICE
This is not a ICE This issue propose printing errno on this :
Probably we want this then: label: -I-ICE, -T-compiler, +T-libs
Code change:
} else { val + n }; <ins> // zero the upper bits let val = val as u128; let val = (val << amt) >> amt; </ins> (Self { val: val as u128, ty: self.ty, }, oflo) } else { <del> let (min, max) = match int { Integer::I8 => (u8::min_value() as u128, u8::max_value() as u128), Integer::I16 => (u16::min_value() as u128, u16::max_value() as u128), Integer::I32 => (u32::min_value() as u128, u32::max_value() as u128), Integer::I64 => (u64::min_value() as u128, u64::max_value() as u128), Integer::I128 => (u128::min_value(), u128::max_value()), }; </del> <ins> let max = u128::max_value() >> amt; </ins> let val = self.val; let oflo = val > max - n; let val = if oflo { <del> min + (n - (max - val) - 1) </del> <ins> n - (max - val) - 1 </ins> } else { val + n };

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:
pub fn fully_expand_fragment(&mut self, input_fragment: AstFragment) -> AstFragment { let orig_expansion_data = self.cx.current_expansion.clone(); let orig_force_mode = self.cx.force_mode; <del> self.cx.current_expansion.depth = 0; </del> // Collect all macro invocations and replace them with placeholders. let (mut fragment_with_placeholders, mut invocations) =

Related discussion:
text: I tried this code: I expected to see this happen: An error message about exceeding some recursion limit Instead, this happened: Tested on stable 1.51.0 + <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that the crash also occurs without . Based on testing with Godbolt, this doesn't seem to be a regression, or at least not a recent one.
Assigning as part of the prioritization working group discussion and removing . modify labels -I-prioritize +P-medium
Issue might be in this line: Calls , which then calls : And sets to , which would result in stack overflow because the recursion limit is never reached.
claim
Bug is confusing to track down, so I am no longer working on this. For people who are interested, here is the log when the loop is encountered: release-assignment
The issue is part of a bigger problem, that seems to ignore the recursion limit. This snippet below compiles successfully instead of reporting an error:
Seems to be a regression between and by testing on Godbolt. I suspect from caused the regression, but I'm not sure. label regression-untriaged
Code change:
.RE .TP fB-lfR [fIKINDfR=]fINAMEfR <del> Link the generated crate(s) to the specified native library fINAMEfR. </del> <ins> Link the generated crate(s) to the specified library fINAMEfR. </ins> The optional fIKINDfR can be one of fIstaticfR, fIdylibfR, or fIframeworkfR. If omitted, fIdylibfR is assumed.

Related discussion:
text: Now, run the following You get the following error: A simple fix to this is to add at the beginning of , but that should not be unnecessary. Reproduces on nightly.
This is currently working as intended, the flags only work for specifying the immediate set of dependencies (those listed in ), and transitive dependencies must be found through paths. You can use to make sure that only transitive dependencies are found in those paths.
If that is the intended behavior, then please reopen this issue and mark it as a documentation problem. I cannot find where this distinction is explained. This section of would imply that: / are for use with native libraries only, not even mentioning the KIND. by itself will not actually search for crates in that directory. should be used for telling rust where to locate any crate and is an intuitive solution to errors like For reference, how do you thus indicate to rust where to locate a crate whose filename does not follow the pattern?
Yeah seems reasonable to leave open as a docs issue. Not sure exhaustive documentation should go into the message but the man page could certainly be up. That... can't actually be done I don't think. The only way the compiler looks for transitive dependencies is via where is the name of the crate.
Code change:
/// let localhost = Ipv4Addr::new(127, 0, 0, 1); /// assert_eq!("127.0.0.1".parse(), Ok(localhost)); /// assert_eq!(localhost.is_loopback(), true); <ins> /// assert!("012.004.002.000".parse::<Ipv4Addr>().is_err()); // all octets are in octal /// assert!("0000000.0.0.0".parse::<Ipv4Addr>().is_err()); // first octet is a zero in octal /// assert!("0xcb.0x0.0x71.0x00".parse::<Ipv4Addr>().is_err()); // all octets are in hex </ins> /// ``` #[derive(Copy)] #[stable(feature = "rust1", since = "1.0.0")]

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:
/// let localhost = Ipv4Addr::new(127, 0, 0, 1); /// assert_eq!("127.0.0.1".parse(), Ok(localhost)); /// assert_eq!(localhost.is_loopback(), true); <ins> /// assert!("012.004.002.000".parse::<Ipv4Addr>().is_err()); // all octets are in octal /// assert!("0000000.0.0.0".parse::<Ipv4Addr>().is_err()); // first octet is a zero in octal /// assert!("0xcb.0x0.0x71.0x00".parse::<Ipv4Addr>().is_err()); // all octets are in hex </ins> /// ``` #[derive(Copy)] #[stable(feature = "rust1", since = "1.0.0")]

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:
/// let localhost = Ipv4Addr::new(127, 0, 0, 1); /// assert_eq!("127.0.0.1".parse(), Ok(localhost)); /// assert_eq!(localhost.is_loopback(), true); <ins> /// assert!("012.004.002.000".parse::<Ipv4Addr>().is_err()); // all octets are in octal /// assert!("0000000.0.0.0".parse::<Ipv4Addr>().is_err()); // first octet is a zero in octal /// assert!("0xcb.0x0.0x71.0x00".parse::<Ipv4Addr>().is_err()); // all octets are in hex </ins> /// ``` #[derive(Copy)] #[stable(feature = "rust1", since = "1.0.0")]

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.
Code change:
/// let localhost = Ipv4Addr::new(127, 0, 0, 1); /// assert_eq!("127.0.0.1".parse(), Ok(localhost)); /// assert_eq!(localhost.is_loopback(), true); <ins> /// assert!("012.004.002.000".parse::<Ipv4Addr>().is_err()); // all octets are in octal /// assert!("0000000.0.0.0".parse::<Ipv4Addr>().is_err()); // first octet is a zero in octal /// assert!("0xcb.0x0.0x71.0x00".parse::<Ipv4Addr>().is_err()); // all octets are in hex </ins> /// ``` #[derive(Copy)] #[stable(feature = "rust1", since = "1.0.0")]

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:
/// let localhost = Ipv4Addr::new(127, 0, 0, 1); /// assert_eq!("127.0.0.1".parse(), Ok(localhost)); /// assert_eq!(localhost.is_loopback(), true); <ins> /// assert!("012.004.002.000".parse::<Ipv4Addr>().is_err()); // all octets are in octal /// assert!("0000000.0.0.0".parse::<Ipv4Addr>().is_err()); // first octet is a zero in octal /// assert!("0xcb.0x0.0x71.0x00".parse::<Ipv4Addr>().is_err()); // all octets are in hex </ins> /// ``` #[derive(Copy)] #[stable(feature = "rust1", since = "1.0.0")]

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:
/// let localhost = Ipv4Addr::new(127, 0, 0, 1); /// assert_eq!("127.0.0.1".parse(), Ok(localhost)); /// assert_eq!(localhost.is_loopback(), true); <ins> /// assert!("012.004.002.000".parse::<Ipv4Addr>().is_err()); // all octets are in octal /// assert!("0000000.0.0.0".parse::<Ipv4Addr>().is_err()); // first octet is a zero in octal /// assert!("0xcb.0x0.0x71.0x00".parse::<Ipv4Addr>().is_err()); // all octets are in hex </ins> /// ``` #[derive(Copy)] #[stable(feature = "rust1", since = "1.0.0")]

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:
/// let localhost = Ipv4Addr::new(127, 0, 0, 1); /// assert_eq!("127.0.0.1".parse(), Ok(localhost)); /// assert_eq!(localhost.is_loopback(), true); <ins> /// assert!("012.004.002.000".parse::<Ipv4Addr>().is_err()); // all octets are in octal /// assert!("0000000.0.0.0".parse::<Ipv4Addr>().is_err()); // first octet is a zero in octal /// assert!("0xcb.0x0.0x71.0x00".parse::<Ipv4Addr>().is_err()); // all octets are in hex </ins> /// ``` #[derive(Copy)] #[stable(feature = "rust1", since = "1.0.0")]

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:
.collect(), _ => Vec::new(), }; <ins> candidates.retain(|candidate| *candidate != self.tcx.parent(result.callee.def_id)); </ins> return Err(IllegalSizedBound(candidates, needs_mut, span)); }

Related discussion:
text: Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.