jiebi/CodeConvo huggingface dataset:
Change:
# If this file is modified, then llvm will be forcibly cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2014-01-27 </del> <ins> 2014-02-11 </ins>

Discussion:
This code Will generate this IR under Yes, that is a of length 7. I have no idea why this is getting generated, I'm trying to narrow down which pass is generating this, but that is absolutely awful code to generate for such a simple operation. I would expect this function to generate two stores, one of the discriminant and one of the value. Now change the program to have in front of the enum, and we get this code:
cc
I would expect similar code generation with as well as with no annotation. Is this because we're attempting to zero-out the discriminant padding?
Look at the asm. This may actually not be so bad unless the is getting lowered to a true .
Here is the asm. It is not actually generating a call to :
the equivalent to no in this case would be , fwiw.
I agree that the assembly doesn't look that bad, but this is still completely unnecessary, no? I was looking at assembly with huge waterfalls of moving al/ax/eax/rax over and over again. I don't think this is a closed bug because this is a real problem. This may not be a high priority bug, but our assembly is certainly doing things that it doesn't need to do.
Is this ?
Aha, I see the problem: SROA happened, split up our struct into 3 elements, one of which is the padding, and stored the padding. The solution is to add , like . Closing again as a dupe.
It may be, but I don't know enough about LLVM's optimizations to know whether that would help or not.
It would be possible to make the type , and that might make the code seen here less bad, but I don't know if LLVM would be less able to optimize code that accesses the discriminant in that case. It would also be possible to make more complex and have it avoid filling in alignment padding for bytes where none of the variants have fields (so → , → ). We might need this information anyway for .
Patch has been submitted to LLVM upstream.
Change:
<ins> // Copyright 2018 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() { let a = (1.0).pow(1.0); //~ ERROR can't call method `pow` on ambiguous numeric type } </ins>

Discussion:
Please note the
The literal's span should point inside the parenthesis. Probably needs a change to in .
I'm interested in working on this.
feel free to reach out for any help you might need! I believe that you should verify if changing the span being used in the AST for literals changes the suggestion output. If it doesn't, it means that the problem is not at the parser level, but when lowering to HIR. If that is the case, we need to dig deeper, but I'll be here to help you with that.
Change:
UnstableFeatures, Stability, UnconditionalRecursion, <del> PrivateNoMangleFns, </del> <ins> InvalidNoMangleItems, </ins> ); add_builtin_with_new!(sess,

Discussion:
Will not actually be exported in the resulting object. There are two obvious fixes, the first being to expand on my pub-not-exported lint to warn you that this will not work, the second being to fix the compiler to export the symbol with the appropriate value (Without altering the existing inlining behaviour, although it may give a more reasonable option for cases like trying to take the address of a item). Happy to work on either, although I would need a mentor for the second part.
I'm not sure what you mean by it not being exported. It might not be visible as a symbol (if you're linking with some C code or something), but you can certainly reference that item from another Rust crate.
Sorry for not being clear. That's exactly what I meant, the symbol is not visible in the resulting object. This is pretty confusing (I've been doing a lot of C(++) <-Rust lately and I'm trying to make the compiler warn people about all the things that have tripped me up)
I think the right option is to expand the lint. The whole difference between and is that the former isn't guaranteed to have a location in memory. To a C programmer it's like a variable.
Sounds totally reasonable. I'll expand the lint.
Ah, I see now. I didn't know there was a lint for on items that don't export a symbol. That explains a lot!
Change:
| cut -d ' ' -f 2) case $CFG_CLANG_VERSION in <del> (3.2* | 3.3* | 3.4* | 3.5* | 3.6*) </del> <ins> (3.2* | 3.3* | 3.4* | 3.5* | 3.6* | 3.7*) </ins> step_msg "found ok version of CLANG: $CFG_CLANG_VERSION" if [ -z "$CC" ] then

Discussion:
This is with clang built from source. Guessing something in is not right. compare: What was ?
needs 3.7. I got this.
Change:
--> $DIR/two-phase-across-loop.rs:17:22 | LL |         strings.push(foo.get_string()); <del> |                      ^^^^^^^^^^^^^^^^ `foo` was mutably borrowed here in the previous iteration of the loop </del> <ins> |         -------------^^^^^^^^^^^^^^^^- |         |            | |         |            `foo` was mutably borrowed here in the previous iteration of the loop |         first borrow used here, in later iteration of loop </ins> error: aborting due to previous error

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: It looks like the error is pointing to the wrong spot in the code and is quite misleading. Ideally the output should mention that is still mutably borrowed because it holds a reference to between loops. Or something, im not actually sure :P I have confirmed that this occurs in both the latest stable (1.62.1) and nightly () <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
With the proposed the output will be like this:
Change:
use crate::channel; use crate::compile; use crate::config::TargetSelection; <ins> use crate::doc::DocumentationFormat; </ins> use crate::tarball::{GeneratedTarball, OverlayKind, Tarball}; use crate::tool::{self, Tool}; use crate::util::{exe, is_dylib, output, t, timeit};

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
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. #![feature(rustc_attrs)] #![allow(unused)] fn f() { let mut x: Vec<()> = Vec::new(); || { || { x.push(()) } }; } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
This works: This does not and gives a confusing error: The error:
This also gives a confusing error: The following works:
None of these examples don't compile today, so I'm presuming this is fixed and marking E-needstest.
Can I take this issue and put this into a run-pass test?
Sounds good to me, though compile-pass would probably be sufficient - grep for .
Ok. Will do. Btw, it looks like this commit was fixed by .
Change:
catenated = '' if lastline is not None: <del> raise RuntimeError('Trailing backslash in the end of file') </del> <ins> print_err(lineno, line, 'Trailing backslash at the end of the file') </ins> LINE_PATTERN = re.compile(r''' (?<=(?<!S)@)(?P<negated>!?)

Discussion:
When a doc test fails, the console output looks like this: A traceback should only be shown if there was an error in the python script itself - in this case it should only show the matches error, something like this:
cc me. I'm surely willing to fix that as soon as I get enough spare time.
did you ever get a chance to look at this? (Do you know if the situation has changed?)
No, also I'm not aware of any update. Looks like that I've forgotten this at that time (as flt2dec was being matured); I have virtually no energy to contribute nowadays, so I probably cannot work on this right now.
Change:
<ins> fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ { *x //~^ ERROR the trait bound `u32: std::future::Future` is not satisfied } fn main() { let _ = test_ref & u; //~ ERROR cannot find value `u` in this scope } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Possibly related to , though the panic happens at a different place.
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-01 to nightly-2020-05-02 regressed nightly: nightly-2020-03-28 searched commits: from to regressed commit:
It is caused by a different underlying cause to .
The underlying issue is a bad interaction in the following code with the call to (called by ) which expects there not to be any unresolved lifetimes. This happens because the code is actually parsed and evaluated as ( and ).
Change:
<ins> // Copyright 2016 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() { let args: Vec<String> = std::env::args().collect(); if args.len() > 1 && args[1] == "run_test" { let _ = std::thread::spawn(|| { panic!(); }).join(); panic!(); } else { let test = std::process::Command::new(&args[0]).arg("run_test").output().unwrap(); assert!(!test.status.success()); let err = String::from_utf8_lossy(&test.stderr); let mut it = err.lines(); assert_eq!(it.next().map(|l| l.starts_with("thread '<unnamed>' panicked at")), Some(true)); assert_eq!(it.next(), Some("note: Run with `RUST_BACKTRACE=1` for a backtrace.")); assert_eq!(it.next().map(|l| l.starts_with("thread '<main>' panicked at")), Some(true)); assert_eq!(it.next(), None); } } </ins>

Discussion:
Given this code, the failure message looks like this This is problematic as the useful information (the message passed to )is buried inside the sentence. It'd be better if the failure message was on its own line, something akin to: This format also allows for space to mention other useful information (e.g. issue ).
Is this still something we want to do? I have a small patch that implements something like this and would also but I'm not sure how many people really want another format for panic messages. Changing the format might also break existing tools (for example, there are several run-tests in this repo that expect a panic).
I'd be all for it, I still find those messages hard to read even after all these years.
you should submit it
The pull request didn't really fix this bug... should I make another bug like this, or is this a wontfix now?
Oh sorry, that's because I didn't change the original pull request message. Perhaps can comment on this?
This is somewhat of a wontfix for now, the discussion of concluded that we likely don't want to radically change the format for now due to the concurrency/verbosity reasons mentioned. If this becomes extra onerous in the future, however, we can consider reformatting these messages.

Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)
Change:
} enum EnumVariantField { <del> Named { </del> <ins> Named { //~ NOTE while parsing this struct </ins> field!(oopsies:()), //~^ NOTE macros cannot expand to struct fields //~| ERROR unexpected token: `!` //~| unexpected token after this field!(oopsies2:()), <del> //~^ NOTE macros cannot expand to struct fields //~| ERROR unexpected token: `!` //~| unexpected token after this </del> }, } union Union { <ins> //~^ NOTE while parsing this union </ins> A: u32, field!(oopsies:()), //~^ NOTE macros cannot expand to union fields //~| ERROR unexpected token: `!` <del> //~| unexpected token after this </del> <ins> //~| NOTE unexpected token after this </ins> B: u32, field!(recovers:()), <del> //~^ NOTE macros cannot expand to union fields </del> <ins> } // https://github.com/rust-lang/rust/issues/114636 #[derive(Debug)] pub struct Lazy { //~^ NOTE while parsing this struct unreachable!() //~^ NOTE macros cannot expand to struct fields </ins> //~| ERROR unexpected token: `!` <del> //~| unexpected token after this </del> <ins> //~| NOTE unexpected token after this </ins> } <ins> fn main() {} </ins>

Discussion:
<!-- 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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-08-05 Regression in cc
This is probably because it recovers from it and gives the field no name. We should probably give it the macro's name instead I believe this is the offending line:
An alternative approach would be to directly throw an error instead of allowing the parser to continue, imo.
label -needs-triage
Change:
let main_file = input.file_name(); let input_is_stdin = main_file == FileName::Stdin; <del> let parse_session = ParseSess::new(config)?; </del> <ins> let mut parse_session = ParseSess::new(config)?; </ins> if config.skip_children() && parse_session.ignore_file(&main_file) { return Ok(FormatReport::new()); }

Discussion:
<!-- 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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Probably a duplicate of , and hopefully will be fixed by .
no, I checked, while is fixed, this one isn't :(
Change:
[[package]] name = "libc" <del> version = "0.2.77" </del> <ins> version = "0.2.79" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "f2f96b10ec2560088a8e76961b00d47107b3a625fecb76dedb29ee7ccbf98235" </del> <ins> checksum = "2448f6066e80e3bfc792e9c98bf705b4b0fc6e8ef5b43e5889aff0eaa9c58743" </ins> dependencies = [ "rustc-std-workspace-core", ]

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
/// in the given `Vec<T>`. The collection may reserve more space to speculatively avoid /// frequent reallocations. After calling `try_reserve`, capacity will be /// greater than or equal to `self.len() + additional` if it returns <del> /// `Ok(())`. Does nothing if capacity is already sufficient. </del> <ins> /// `Ok(())`. Does nothing if capacity is already sufficient. This method /// preserves the contents even if an error occurs. </ins> /// /// # Errors ///

Discussion:
Any methods of container types (12 in Rust 1,62.1, including duplicated ones in ), and maybe corresponding methods. - - - - ... and corresponding methods in . Documentations for describes "If the capacity overflows, or the allocator reports a failure, then an error is returned.". However, it does not give any guarantees about whether the content is preserved or not on that error. This guarantee (or absence of the guarantee) should be explicitly described.
At least for (and -based things like ) it's obvious to guarantee that, so we might as well. (Thank you, Rust, for insisting on move-is- so we don't have the "what if the move constructor panics" problems like C++.) I think it'll need to be to hashbrown before we can consider promising it for /, through -- there's no guarantee in <https://rust-
Modulo needing to add it in hashbrown, shall we see if we have consensus to say that failures preserve the current contents? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Please feel free to post a PR for this.
Created a PR for this.
Change:
/// /// handler.join().unwrap(); /// ``` <ins> /// /// [naming-threads]: ./index.html#naming-threads </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn name(mut self, name: String) -> Builder { self.name = Some(name);

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR:
Change:
-                                          // + literal: Const { ty: unsafe fn(Option<T>) -> T {Option::<T>::unwrap_unchecked}, val: Value(<ZST>) } +         StorageLive(_3);                 // scope 0 at $DIR/unwrap_unchecked.rs:+1:9: +1:27 +         _4 = discriminant(_2);           // scope 1 at $SRC_DIR/core/src/option.rs:LL:COL <del> +         switchInt(move _4) -> [0: bb1, 1: bb2, otherwise: bb1]; // scope 1 at $SRC_DIR/core/src/option.rs:LL:COL </del> <ins> +         switchInt(move _4) -> [1: bb2, otherwise: bb1]; // scope 1 at $SRC_DIR/core/src/option.rs:LL:COL </ins> } bb1: {

Discussion:
<!-- 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. --I tried this code: I expected to see this happen: no branch instructions emitted, makes an assumption that is , so should be inlined and optimized as a panic. Instead, this happened: there is a discriminant check still emitted. <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on: nightly-2023-03-26 <!-- Provide the version you are using that has the regression. --See godbolt: Regression occurred in (cc searched nightlies: from nightly-2023-03-01 to nightly-2023-04-01 regressed nightly: nightly-2023-03-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details<details</summary(if you want to test on replace with ) </details<details</summary</details originally noticed the problem and opened , then suggested that this is a compiler issue, then that this is a regression, then bisected and opened this issue.
The end of this regression window is over 2 weeks from now. Why? Godbolt usually has pretty old nightlies. If I add : you can see we have duplicate switch targets, which means that either this commit is broken or godbolt doesn't have it:
godbolt seems to have ?
Because I knew that reproduces the regression, and wanted to cut some time bisecting. For reference I can reproduce the same issue with . <details<summary+nightly-2023-04-19 --emit=mir</summary</details
To be clear, separate from this issue I believe that this MIR: is a bug. I do not know what impact resolving that would have on this issue. But the helper that combines switch targets was (notionally) supposed to prevent this.
Yeah, I'm pretty sure that is the root cause.
WG-prioritization assigning priority (). label -I-prioritize +P-medium