jiebi/CodeConvo huggingface dataset:
Code change:
&mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

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:
&mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

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:
&mut self, radix: u32, max_digits: Option<usize>, <ins> allow_zero_prefix: bool, </ins> ) -> Option<T> { self.read_atomically(move |p| { let mut result = T::ZERO; let mut digit_count = 0; <ins> let has_leading_zero = p.peek_char() == Some('0'); </ins> while let Some(digit) = p.read_atomically(|p| p.read_char()?.to_digit(radix)) { result = result.checked_mul(radix)?;

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:
<ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. ---rs has been updated with a workaround, so the reproduction described below will need adapting (e.g. check out that repo from around or earlier, since that will not include the workaround in ) problem exhibits itself only with certain numbers of codegen-units. The default setting for codegen-units is host dependent (the default is chosen, in part, as a function of the number of cores the host has available, in order to parallelize the code-generation performed by LLVM). In my own experiments, the problem is masked (does not arise) for codegen-units={1,2,4,8}, and the problem does arise for codegen-units={16,32,64,128,256}. You are best off passing explicit when investigating this, just to ward against that being an invisible factor in the experiments. (bug report follows below) I tried this code: I expected to see this happen: succeeds in debug mode. Instead, this happened: fails in debug mode. *isn't immediately obvious why would cause the problem searched nightlies: from nightly-2023-03-27 to nightly-2023-04-02 regressed nightly: nightly-2023-04-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-nightly-to-nightly -regression-untriaged --
I forked and minimized the reproducible example down to simply having a type (but not a value) with in a crate (and then adding that proc macro crate as a dependency of another crate). You can find it here: (just run in ) Here is a workaround for the crate:
WG-prioritization assigning priority ().
Code change:
<ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

Related discussion:
text: label -I-prioritize +P-high +T-compiler
TBH it's not clear to me how alignment checks would end up causing linker errors, but since this seems bisected to , let's at the very least notify the PR's author
I already looked over this and was also mystified. I suppose I could take another look? I know almost completely nothing about wasm so I'm not hopeful.
Builds fine: Same linker error: As a mitigation for the linker error, users may put this in their (for the workspace!) That only helps with the alignment checks, is still not going to work.
I can build the reproducer, unmodified, if I use LLD. Or suggests this might be a link order issue. That would explain why LLD is fine with the link, but GNU's linker isn't. Actually, that doesn't make much sense because our standard library is already at the end of the link. I'm out of ideas :shrug: I think this is somehow dependent on linker details that I don't know and I'm struggling to educate myself on.
reported this same linker error from . It can be reproduced by creating an empty Cargo project, then running then . I have not managed to minimize this reproducer. The errant symbol is which is defined as: This has the same sort of shape as the non-unwinding panics from the alignment checks and from the standard library UB-detecting assertions. searched nightlies: from nightly-2023-01-01 to nightly-2023-06-09 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsSo this bisects to a rollup then can't find the unrolled perf builds. Manual trials identifies as the source of the regression.
A tiny update: it seems like this problem goes away if you use  (and for me, it also didn't reproduce for many other values for number-of-codegen-units; I won't bother enumerating those here). This was somewhat of a surprise. I need to investigate more to figure out what relevance the codegen unit partitioning has to do with this issue.
Code change:
<ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

Related discussion:
text: If nothing else, it is a halfway decent fallback measure while we continue to investigate the problem.
Wanted to add, that I also ran into this issue. For me, it also occurred while compiling a macro crate. I originally thought it was an issue with , as it happened after I ran a , and the issue was fixed by pinning to a slightly older version: There was a bunch of weird behavior I encountered when trying to uncover the issue. The issue was one. When I made other library upgrade changes, it would cause or fix the breakage. I didn't dive too deeply, but it seems like I was still encountering this issue even when I set the compiler to 1.67. (See this Github Actions build and associated commit: ) So it's possible that going to an old version simply hid the issue, but didn't actually pinpoint where the issue was introduced. Let me know if there's any other information I can provide to help isolate the issue. I've seemingly been able to work around the issue by using , as described earlier: I didn't try the other solution about codegen-units.
One MCVE for the stylist-macros build issue looks like this: Just a stylist-macros crate, with this and : So now I'm switching gears to see if I reduce wasm_bindgen to something smaller, so that we can have a small set of crates to talk about on their own here.
Okay got a pretty impressively tiny MCVE for wasm-bindgen too: In case its not clear, this seems like a pretty simple example that should easily work out of the box. (The use of from the mcve-stylist part of the story seems like an important part of the reproduction.) Still looking. Update: Wow, is it somehow of all things that is causing the problem here? That is ... bizarre, to say the least.
may be relevant. That issue is about not mentioning symbols in the version script such that they don't get exported. Also when applying to the rlib containing the symbols the linker error is fixed, so it seems like the linker doesn't pull in archive members even when the version script mentions it. Edit: For regular dylibs we mention all these symbols in , but for proc macros we only list a couple of internal symbols.
Code change:
<ins> // build-pass // force-host // no-prefer-dynamic // aux-build:exports_no_mangle.rs #![crate_type = "proc-macro"] // Issue #111888: this proc-macro crate imports another crate that itself // exports a no_mangle function. // // That combination was broken for a period of time, because: // // In PR #99944 we *stopped* exporting no_mangle symbols from // proc-macro crates. The constructed linker version script still referred // to them, but resolving that discrepancy was left as a FIXME in the code. // // In PR #108017 we started telling the linker to check (via the // `--no-undefined-version` linker invocation flag) that every symbol referenced // in the "linker version script" is actually present in the linker input. So // the unresolved discrepancy from #99944 started surfacing as a compile-time // error. extern crate exports_no_mangle; </ins>

Related discussion:
text: Edit2: There is a special case for proc macros with the handling to not mention any symbols beyond those required to handle circular dependencies. Fixing should fix this issue too by making the version script a subset of again (apart from a couple of symbols defined outside of archives).
: As an addendum to this: (which was in a rollup, as mentioned) the future-proofing safe-guard of adding to the linker invocation. We can add that same link-arg ourselves as part of further bisection that acts prior to PR . In my own MCVE, when I add that link-arg, I find that the code did compile circa 1.63 even with that flag. The flag stopped working sometime between nightly-2022-08-01 and nightly-2022-08-02. (I have not yet tracked down further than that, since its too old to have per-commit prebuilds archived.) Update: oh, of course, it is almost certainly PR that injected the change in behavior mentioned in the previous paragraph.
See related discussion in https://rust- (I have a branch with a commit that seems to fix this here: ; I hope to have a PR up today, once I get a regression test into place.)
Code change:
"checksum arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)" = "a1e964f9e24d588183fcb43503abda40d288c8657dfc27311516ce2f05675aef" "checksum atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "9a7d5b8723950951411ee34d271d99dddcc2035a16ab25310ea2c8cfd4369652" "checksum autocfg 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "0e49efa51329a5fd37e7c79db4621af617cd4e3e5bc224939808d076077077bf" <del> "checksum backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)" = "1c50b4cb6d852a8567d98bb11c03f91ccec4dfbd88778bc1b92789c624081283" </del> <ins> "checksum backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)" = "2d631cd7af21b7ff796293f1990104e3cdb606852863bac32f000c193aa35dfb" </ins> "checksum backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)" = "6ea90dd7b012b3d1a2cb6bec16670a0db2c95d4e931e84f4047e0460c1b34c8d" "checksum bit-set 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "6f1efcc46c18245a69c38fcc5cc650f16d3a59d034f3106e9ed63748f695730a" "checksum bit-vec 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4440d5cb623bb7390ae27fec0bb6c61111969860f8e3ae198bfa0663645e67cf"

Related discussion:
text: That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs
Code change:
debug!(?cache_projection, ?obligation_projection); match infcx.at(cause, param_env).eq( <del> DefineOpaqueTypes::No, </del> <ins> DefineOpaqueTypes::Yes, </ins> cache_projection, obligation_projection, ) {

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. --Hey! I was trying to make it work somehow with , when the function depends on the other generic parameters. I came to this approach and encountered an ICE. <!-- 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. --: <details<summary<strongOutput</strong</summary<p</p</details
label requires-nightly F-typealiasimpl_trait
Regression in nightly-2023-02-22 Regression in cc
still crashing, rustc 1.77.0-nightly ( 2024-01-08)
Code change:
use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::ty::{fast_reject, TypeFoldable}; use rustc_middle::ty::{ToPredicate, TypeVisitableExt}; <del> use rustc_span::ErrorGuaranteed; </del> <ins> use rustc_span::{ErrorGuaranteed, DUMMY_SP}; </ins> use std::fmt::Debug; pub(super) mod structural_traits;

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'', 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc
Code change:
<ins> #![feature(associated_const_equality)] trait T { type A: S<C<X = 0i32> = 34>; //~^ ERROR associated type bindings are not allowed here } trait S { const C: i32; } fn main() {} </ins>

Related discussion:
text: I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
<del> Subproject commit 648e5b90b49af483d07caa8e413473a4517853d6 </del> <ins> Subproject commit 5cb983338e924ec85898880d60e65f2a1291b7be </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Caused by
I'm working on this.
Code change:
<ins> // Copyright 2014 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 Foo { } impl<T:Copy> Foo for T { } fn take_param<T:Foo>(foo: &T) { } fn main() { let x = box 3i; take_param(&x); //~^ ERROR instantiating a type parameter with an incompatible type } </ins>

Related discussion:
text: Example: This should be fixed by code in .
Nominating for 1.0, P-backcompat-lang.
Assigning 1.0, P-backcompat-lang