jiebi/CodeConvo huggingface dataset:
Code change:
/// /// # Panics /// <del> /// When the number is zero, or if the base is not at least 2; /// it panics in debug mode and the return value is 0 in release mode. </del> <ins> /// This function will panic if `self` is zero, or if `base` is less then 2. </ins> /// /// # Examples ///

Related discussion:
text: Since, from the notes, it seems like the libs-api meeting today said "how about we panic instead of wrap", I'll try to answer my own question from above: I would propose the following rule: Conceptually, the result is first calculated in true ℤ (aka to infinite precision). Then for the non-prefixed versions If that result is undefined (, , etc), then it panics (regardless of compilation mode) If that result is defined and fits in the result type, it's returned. If that result is defined but not in-range for the result type, it panics if overflow checking is enabled, and wraps (mod 2<supN</supfor uN) if overflow checking is disabled. I think that's consistent with all the current precedent. ( also is good reading about the distinction I'm drawing here.)
I would redefine that to include cases where the result is defined but you can't wrap that to the result type, e.g. or . that would cover and
I agree, but was considering that implied by "in ℤ", as that set includes neither −∞ nor ⅈ. (Like how is , not a complex number.)
I'm not necessarily against panicking in that case. I just pointed out how it's a bit inconsistent with the other operations we have on integers. (Whether it makes sense for the other operations to have this difference in behavior between debug and release mode is an interesting discussion too, but I'm afraid that ship has sailed.) The reason we don't always panic on overflow for and etc. is performance. It's simply too costly to do. (We always panic on division by zero because that's both mathematically undefined (even modulo 2<supBITS</sup) and because on some platforms, the native division instruction will signal/abort/trap the program when the right hand side is zero.) We applied the same reasoning to things like and , although one might reasonably argue that for those it might be fine to always panic, since these are not as common as and . (You could then still use if you really want to make sure there's no check, if you're sure it's unnecessary.) That seems reasonable. It'd be nice if it'd still be easy to get the efficient calculation through some usage of or though.
Code change:
/// /// # Panics /// <del> /// When the number is zero, or if the base is not at least 2; /// it panics in debug mode and the return value is 0 in release mode. </del> <ins> /// This function will panic if `self` is zero, or if `base` is less then 2. </ins> /// /// # Examples ///

Related discussion:
text: It looks like llvm isn't smart enough today to turn into simply a count-leading-zeros and a subtract instruction. :(
We discussed this again in the libs-api meeting, and we concluded pretty much the same as rule, meaning that these functions should panic on zero in all compilation modes, since there's not a modulo-2<supN</sup-correct result.
Code change:
<ins> // Issue #3878 // Issue Name: Unused move causes a crash // Abstract: zero-fill to block after drop fn main() { let y = ~1; move y; } </ins>  No newline at end of file

Related discussion:
text: cc
cc
This was caused in the TOML refactor in Cargo, the fallback support to support malformed is likely broken.
Fixes are sent to Cargo, I'll send PRs to rust-lang/rust when they're merged
Submodules landed!
Code change:
unsafe { foo(); //~ ERROR: this function takes at least 2 parameters but 0 parameters were supplied //~^ NOTE the following parameter types were expected <ins> //~| NOTE expected at least 2 parameters </ins> foo(1); //~ ERROR: this function takes at least 2 parameters but 1 parameter was supplied //~^ NOTE the following parameter types were expected <ins> //~| NOTE expected at least 2 parameters </ins> let x: unsafe extern "C" fn(f: isize, x: u8) = foo; //~^ ERROR: mismatched types

Related discussion:
text: From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.
Code change:
fn inner() { let _ = foo!(third); } <ins> #[allow(semicolon_in_expressions_from_macros)] async { let _ = foo!(fourth); }; </ins> }

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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Code change:
<ins> // check-pass // edition:2021 #![feature(async_fn_in_trait)] #![allow(incomplete_features)] use std::future::Future; async fn yield_now() {} trait AsyncIterator { type Item; async fn next(&mut self) -> Option<Self::Item>; } struct YieldingRange { counter: u32, stop: u32, } impl AsyncIterator for YieldingRange { type Item = u32; async fn next(&mut self) -> Option<Self::Item> { if self.counter == self.stop { None } else { let c = self.counter; self.counter += 1; yield_now().await; Some(c) } } } async fn async_main() { let mut x = YieldingRange { counter: 0, stop: 10 }; while let Some(v) = x.next().await { println!("Hi: {v}"); } } fn main() { let _ = async_main(); } </ins>

Related discussion:
text: Example: yields <details<summaryBacktrace</summary</details
cc and
This has to do with late-bound regions and RPITITs. I have a fix, but it's probably not right nor is it cleaned up much. I'll put it up for scrutiny soon though.
Actually nvm, it was a silly little resolver bug.
label +I-ICE +C-bug
Code change:
<ins> // check-pass // edition:2021 #![feature(async_fn_in_trait)] #![allow(incomplete_features)] use std::future::Future; async fn yield_now() {} trait AsyncIterator { type Item; async fn next(&mut self) -> Option<Self::Item>; } struct YieldingRange { counter: u32, stop: u32, } impl AsyncIterator for YieldingRange { type Item = u32; async fn next(&mut self) -> Option<Self::Item> { if self.counter == self.stop { None } else { let c = self.counter; self.counter += 1; yield_now().await; Some(c) } } } async fn async_main() { let mut x = YieldingRange { counter: 0, stop: 10 }; while let Some(v) = x.next().await { println!("Hi: {v}"); } } fn main() { let _ = async_main(); } </ins>

Related discussion:
text: I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by
Code change:
fn add_object(&mut self, path: &Path); fn gc_sections(&mut self, keep_metadata: bool); fn position_independent_executable(&mut self); <ins> fn no_position_independent_executable(&mut self); </ins> fn partial_relro(&mut self); fn full_relro(&mut self); fn optimize(&mut self);

Related discussion:
text: I'm having trouble linking a Rust program to a non-position-independent C library. When I manually remove the flag from the ld step that rustc runs, everything works correctly. I think that should remove the flag for me, but it doesn't. Here's what I think is going on: When I run It runs ld with the flag: But when I read the rustc code , it seems like the intention is that should only be passed to ld when . That is, if we're not compiling a position independent executable, then we should not pass the position independent executable flag to ld. I think what may be happening here is that somehow the defaults from are overriding the command line options I'm setting. This happens with stable and also the nightly I tried:
and are two distinct things. is also unrelated to the option. Interestingly, I do not remember us having an option to disable PIE; we should have one.
I did a bit of reading and here's what I figured out, please correct me if any of this is wrong. Linkers are new to me! Rust builds position independent executables by default on platforms that support it. These platforms have a relocation model of pic in their target config. The is what sets that linker option, except if it's disallowed by . The correct solution to this is to add a codegen flag, or something like that. Does this sound right?
Hi, I am having the same issue. I am trying to link against non-position-independent C library, build process ends without error but results returned by Rust bindings are different (and incorrect) than those returned from clean C implementation. In order to overcome that issue currently I am setting RUSTFLAGS="-C relocation-model=dynamic-no-pic -C linker=./linker" where linker is bash script that wraps cc and filter -pie flags:
I'm also having this problem. I assumed that passing when doing a build would suppress on the linker command line. (cc:
I'm still seeing this issue. Not sure if it's a regression or I'm doing something wrong. I have a "hello world" program in , and when I run , the resulting call to includes . I'm using nightly rust on Ubuntu: .
So, the problem here isn't with rust, but with the linker.
Code change:
fn add_object(&mut self, path: &Path); fn gc_sections(&mut self, keep_metadata: bool); fn position_independent_executable(&mut self); <ins> fn no_position_independent_executable(&mut self); </ins> fn partial_relro(&mut self); fn full_relro(&mut self); fn optimize(&mut self);

Related discussion:
text: In Ubuntu 15.10 and later the default GCC toolchain installed has been compiled with which causes and to be passed to during code generation and to during linking. Now, the linking part is what is important here as rust on most platforms uses as the linker for most targets. So, though no PIC or PIE code may have been generated by , the linker will still try to link as with PIE in mind, breaking when trying to compile with and the like. To work around this will need to see that the linker has been compiled with PIE as the default and pass to the linker if using GCC or something similar for other linkers. Code to do this can be seen in for Tarpaulin though it is only meant for Linux in that state and can be improved greatly if in tree. EDIT: Don't know why Github isn't linking cross-project PRs correctly right now.
Can this issue be resolved by always passing , except when compiling with ?
Sadly, no. In testing I have seen that any build of GCC that was not built with rejects the option and fails to run. This is why in the PR that I linked the linker was queried to see if it was compiled with before tacking on .
So it's came out from the discussion on an issue related to this in tarpaulin that passing -no-pie before -shared (and maybe then -static if it exists for static linkages as well) resolves the issue. I'm going to test this tarpaulin side and I can report back but I feel it would be best if this could be solved rustc side as it can affect any user in a similar situation.
Code change:
discr, variants }, <del> // FIXME(eddyb): using `FieldPlacement::Arbitrary` here results // in lost optimizations, specifically around allocations, see // `test/codegen/{alloc-optimisation,vec-optimizes-away}.rs`. fields: FieldPlacement::Union(1), </del> <ins> fields: FieldPlacement::Arbitrary { offsets: vec![Size::from_bytes(0)], memory_index: vec![0] }, </ins> abi, align, size

Related discussion:
text: In the 2017-12-14 Nightly I've seen a significant (almost 20%) compilation-time increase when I use on my code. And the successive day (2017-12-15) the compilation got a bit slower still and the run-time of the binary also got about 8% slower. The successive days the situation kept going slightly worse. Extracting parts of my code to show compiler/code performance is not easy, so I've composed this benchmark function (that solves an Euler problem. If this code isn't enough I will write other similar benchmarks): <details<summarySource code</summary</detailsCompiled with: host: x86_64-pc-windows-gnu Runtime: 2017-12-13: 0.30 seconds 2017-12-20: 0.53 seconds Asm from the the 2017-12-13 compiler: Asm from the the 2017-12-20 compiler:
Could someone try to reproduce and bisect this?
cc I think
We shouldn't have such big asm differences between successive nightlies, and I don't see anything suspicious in the middle, so it would be good to try and nail down the commit that made the difference.
I see a regression with this code (note: this is distinct from ). the bad code accesses the stack pointer (%rsp) You have a fast network connection and know how to use . Could you please do so? You should grep for to tell if the code is bad - the bad code includes the following line:
I bisected original example, just testing the speed of the executable created by a stage 1 and came upon (PR ) as the culprit: the runtime on my machine is around 0.3 seconds before that commit and around 0.7 seconds after. latest example also has a clear difference. The code before that commit (just disassembling the ): And after:
That's unfortunate. cc
cc
Thanks We're looking into it
just testing the speed of the executable I am not sure if they share the same cause, first a significant compiler performance decrease using --emit=metadata , then the successive Nightly the decrease of the produced binary performance.
They should not. However, quite a few big commits landed in the Dec 14 nightly.
Code change:
discr, variants }, <del> // FIXME(eddyb): using `FieldPlacement::Arbitrary` here results // in lost optimizations, specifically around allocations, see // `test/codegen/{alloc-optimisation,vec-optimizes-away}.rs`. fields: FieldPlacement::Union(1), </del> <ins> fields: FieldPlacement::Arbitrary { offsets: vec![Size::from_bytes(0)], memory_index: vec![0] }, </ins> abi, align, size

Related discussion:
text: If you could provide an example that exhibits the slowdown with , that would allow us to fix it (is the Dec 13 nightly faster than the Dec 14 nightly which has the same speed, but worse runtime performance, than the Dec 15 nightly?)
The last nightly (2017-12-21) has fixed all three problems. Despite some attempts I failed finding a small amount of code that shows a significant compilation slowdown from 2017-12-14 to 2017-12-20, perhaps it's a more diffuse problem that emerges from compiling my whole big amount of code. I am sorry. I don't fully understand your question, but I try to answer creating a table with some data for some of the last Nightlies: Rustc version --emit=metadata Opt build Binary size Run-time 1.24.0-nightly 2017-12-11 4.32 49.78 12.93 1.24.0-nightly 2017-12-12 4.31 48.50 12.84 1.24.0-nightly 2017-12-13 5.15 50.69 12.86 1.24.0-nightly 2017-12-15 5.33 52.98 14.04 1.24.0-nightly 2017-12-17 5.44 53.31 14.03 1.24.0-nightly 2017-12-20 5.47 54.49 14.14 1.24.0-nightly 2017-12-21 4.28 48.82 12.96 The --emit=metadata is a check time. The Opt build is the compilation time for a well optimized build. The binary size is stripped and in bytes. The times are all in seconds.
EDIT: told me about , so the range is .... EDIT2: at a quick glance, none of those changes should affect binary size or run time. How many times have you run each of these? How much do they vary?
Code change:
discr, variants }, <del> // FIXME(eddyb): using `FieldPlacement::Arbitrary` here results // in lost optimizations, specifically around allocations, see // `test/codegen/{alloc-optimisation,vec-optimizes-away}.rs`. fields: FieldPlacement::Union(1), </del> <ins> fields: FieldPlacement::Arbitrary { offsets: vec![Size::from_bytes(0)], memory_index: vec![0] }, </ins> abi, align, size

Related discussion:
text: They should be: rustc 1.24.0-nightly ( 2017-12-20) binary: rustc commit-hash: commit-date: 2017-12-20 host: x8664-pc-windows-gnu release: 1.24.0-nightly LLVM version: 4.0 rustc 1.24.0-nightly ( 2017-12-21) binary: rustc commit-hash: commit-date: 2017-12-21 host: x8664-pc-windows-gnu release: 1.24.0-nightly LLVM version: 4.0 Mixing up things seems quite easy here.
Ah, that's why I asked, so the range is .... Still not seeing anything clearly relevant, but maybe someone else from does?
The --emit=metadata times are computed as the minimum of four tries. Their variance is very small (on the order of +-0.05) so I think they are reliable. The binary run-time is the minimum of 5 runs, their variance is higher perhaps because they do some I/O, despite using a SSD, about +-0.12. The compilation is slow so there I've done only one time, so those values are the less reliable, but differences above 1.5 seconds should be reliable.
For the compilation time issue, maybe there was a bug in NLL that made it active without it being enabled. For the run-time issue, we need to actually investigate this.
As in, investigate the cause of the run-time fluctuations and how it unregressed?
This is my good old friend the torpedo. LLVM optimizes into this: This is basically equivalent to this pseudo-Rust code After the "non-constant-address" write is generated, LLVM is sunk - LLVM has no way of getting rid of the non constant address, and no way of optimizing accesses to the target with that non-constant address.
Upstream LLVM (that's the yet-to-be-released LLVM 6) has this patch, which avoids the SimplifyCfg sink problem by not running sinking before inlining I have confirmed that - e.g. this code is optimized correctly with the new Until then, I think representing small enums using a struct (rather than an array) should work around this problem.
Code change:
discr, variants }, <del> // FIXME(eddyb): using `FieldPlacement::Arbitrary` here results // in lost optimizations, specifically around allocations, see // `test/codegen/{alloc-optimisation,vec-optimizes-away}.rs`. fields: FieldPlacement::Union(1), </del> <ins> fields: FieldPlacement::Arbitrary { offsets: vec![Size::from_bytes(0)], memory_index: vec![0] }, </ins> abi, align, size

Related discussion:
text: With the 2017-12-22 Nightly all the problems are back: Rustc version --emit=metadata Opt build Binary size Run-time 1.24.0-nightly 2017-12-22 5.36 53.57 13.96
Coud you open a PR that turns small unions into LLVM structs (rather than arrays)? That should fix the problem.
The binaries generated by the last Nightly (1.24.0-nightly 2017-12-25) is further few percents slower (perhaps because of thinLTO?), the compilation times can't be compared now.
Is there more stable measure besides compile time / run time? They can be affected too easily by the environment especially when the run time is expected to take less than 1 second. The generated assembly size seems to be a good measure.
Please re-test next nightly and reopen if not fixed.
The run-time of the binary is now OK. The compilation time with --emit=metadata is still quite large.
Can you open a separate one for compilation times? Seems to be a separate issue.
, I've tried here:
Code change:
discr, variants }, <del> // FIXME(eddyb): using `FieldPlacement::Arbitrary` here results // in lost optimizations, specifically around allocations, see // `test/codegen/{alloc-optimisation,vec-optimizes-away}.rs`. fields: FieldPlacement::Union(1), </del> <ins> fields: FieldPlacement::Arbitrary { offsets: vec![Size::from_bytes(0)], memory_index: vec![0] }, </ins> abi, align, size

Related discussion:
text: I was looking at the generated asm for to see what happens to the array, and was surprised to see a large function with 5(!) call sites for . The generated code doesn't seem to vary with the number of elements in the array. That got me to compare with the functionally equivalent code: which doesn't yield the same assembly at all. The first difference being that the latter doesn't even store the array (only the strs) while the former does. That got me even further in comparing with equivalent loops, up to the extreme (and stupid): vs. The latter generates the simplest code possible: The former not so much:
Documenting my thinking in the hopes that it will be useful, or at least that someone will correct me via Campbell's Law. We know that the ASM outputs are different, so let's go back a few steps until we can find where in the toolchain we want to add our improvement. I compiled this on 1.19 with , but the important thing to note is that while iterany is quite bloated, it looks like the for loop has already been optimized: So is just as trivial in LLVM bytecode as it is in assembler - whatever optimizations we needed to do have already happened. We need to go back farther. . Notice that the tables have turned! is more concise than , so the code we need to add should change the MIR output. Note that . So the problem here seems to be that we aren't inlining before we generate LLVM bytecode. But that answer doesn't satisfy me either, because neither the nor the has any calls to , and in fact . So... one of these things is happening: 're failing to inline , and we haven't noticed because LLVM's been inlining this code for us. LLVM doesn't have as much knowledge as we do, so it can't do as good a job as we theoretically could. 've been looking at unoptimized MIR this whole time. This hypothesis seems to be borne out by the fact that when I rerun rustc without optimizations, I get exactly the same MIR output. But , and ? It's possible that both of these hypotheses are correct; maybe this is unoptimized MIR, because the MIR optimizations are doing absolutely nothing to this file!