jiebi/CodeConvo huggingface dataset:
Change:
.section-header:hover a:before { position: absolute; left: -25px; <ins> padding-right: 10px; /* avoid gap that causes hover to disappear */ </ins> content: '200200a72002'; }

Discussion:
Some of the section anchors that appear when you hover over an item can be difficult to click. It seems to disappear when the mouse transitions over the spacing between the item and the symbol. ! Tested on a variety of browsers, all seem to behave similarly. Rust 1.25 seems OK (there isn't as much spacing). I only notice this on nightly (1.26.0-nightly ( 2018-03-28)).
There is already a PR to fix it .
Resolving? has been merged.
Oh indeed!
Actually it still happens with section headers. I have a small patch I'm testing out to deal with that.
Change:
Ok(None) => { let tcx = self.selcx.tcx(); pending_obligation.stalled_on = <del> trait_ref_type_vars(self.selcx, data.to_poly_trait_ref(tcx)); </del> <ins> trait_ref_infer_vars(self.selcx, data.to_poly_trait_ref(tcx)); </ins> ProcessResult::Unchanged } Ok(Some(os)) => ProcessResult::Changed(mk_pending(infcx, os)),

Discussion:
I've come up with this example (): My understanding is that the error is caused by the obligation being on just (which means it's not retried when is unified with ), whereas it should be stalled on both and so that it's retried when either changes. Right now is limited to type inference variables, so its representation will need to change, and will need to expose constants too. I believe ran into this as well, but for WF obligations, not trait ones. I'm self-assigning this because I'm working on the fix (as part of a larger effort). cc
Note to self: the PR fixing this should also test this example (): The reason for this is that this second example has the type and const inference variables in different generic args of , meaning fixing it also requires changing this to :
I've definitely noticed problems with inference involving consts before, but wasn't able to pin down where the issue was stemming from. It would be great if this could be addressed once and for all.
Change:
use crate::const_eval::error_to_const_error; use crate::interpret::{ <del> self, compile_time_machine, intern_const_alloc_recursive, AllocId, Allocation, Frame, ImmTy, Immediate, InternKind, InterpCx, LocalState, LocalValue, Memory, MemoryKind, OpTy, Operand as InterpOperand, PlaceTy, Pointer, ScalarMaybeUninit, StackPopCleanup, </del> <ins> self, compile_time_machine, AllocId, Allocation, Frame, ImmTy, Immediate, InterpCx, LocalState, LocalValue, Memory, MemoryKind, OpTy, Operand as InterpOperand, PlaceTy, Pointer, ScalarMaybeUninit, StackPopCleanup, </ins> }; use crate::transform::{MirPass, MirSource};

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. --code from ./src/test/ui/consts/constconstructor/const-construct- <!-- 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. --rustc @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Might be caused by That should have reduced the number of ICEs, not increased it, but who knows.^^

<!-- 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. --core reduced from <!-- 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. --: repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This does not reproduce with though, so it's a very recent regression.
` produces the same error it seems.
Change:
} } } <del> true </del> } fn visit_foreign_item_inner(

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
} match (true, false) { <del> (true, false, false) => () //~ ERROR mismatched types: expected `(bool,bool)` but found `(bool,bool,bool)` (expected a tuple with 2 elements but found one with 3 elements) </del> <ins> (true, false, false) => () //~ ERROR mismatched types: expected `(bool,bool)` but found tuple (expected a tuple with 2 elements but found one with 3 elements) </ins> } match (true, false) {

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
impl_trait_defs: Vec::new(), impl_trait_bounds: Vec::new(), allow_try_trait: Some([sym::try_trait_v2, sym::yeet_desugar_details][..].into()), <del> allow_gen_future: Some([sym::gen_future][..].into()), </del> <ins> allow_gen_future: Some([sym::gen_future, sym::closure_track_caller][..].into()), </ins> allow_into_future: Some([sym::into_future][..].into()), generics_def_id_map: Default::default(), };

Discussion:
I tried: I expected the seventh line to be the panic location, but I got this: <details<summaryWith <codeRUSTBACKTRACE=1</code</summary</details%20-%3E%20!%20%7B%0A%20%20%20%20panic!()%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20futures%3A%3Aexecutor%3A%3Ablockon(async%20%7B%20panic().await%20%7D)%3B%0A%7D%0A) (tried using nightly 2020-11-06 ) I can achieve the result I expected by implementing a manually: Output: %5D%0A%0Ause%20std%3A%3A%7B%0A%20%20%20%20future%3A%3AFuture%2C%0A%20%20%20%20pin%3A%3APin%2C%0A%20%20%20%20task%3A%3A%7BContext%2C%20Poll%7D%2C%0A%7D%3B%0A%0Astruct%20Panic%3B%0A%0Aimpl%20Future%20for%20Panic%20%7B%0A%20%20%20%20type%20Output%20%3D%20!%3B%0A%0A%20%20%20%20%23%5Btrackcaller%5D%0A%20%20%20%20fn%20poll(self%3A%20Pin%3C%26mut%20Self%3E%2C%20%3A%20%26mut%20Context%3C%27%3E)%20-%3E%20Poll%3CSelf%3A%3AOutput%3E%20%7B%0A%20%20%20%20%20%20%20%20panic!

()%0A%20%20%20%20%7D%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20futures%3A%3Aexecutor%3A%3Ablockon()%3B%0A%7D%0A) I noticed that (in the backtrace) the compiler generated a closure (?) for the , so may be related. modify labels: A-async-await A-attributes
This seems to be working correctly. The call to does not actually panic, so the does nothing. just returns a future that, when polled, will panic.
But I expect it to work further: automatically generates the I implemented manually, with on and the generated closure/. (Feature request) It's even better if could work on blocks as well.
Sorry for my wrong interpretation of this issue. But currently on s does nothing and compiles without warning, so maybe this is also a ?
Since the call to an can never panic (it always returns an ), I think forwarding the attribute to the returned closure would make sense. This would require impementing (if only on nightly), so that the desugaring can forward as needed.
Since this issue was classified as a feature request, I edited the title to make it clear.
Forwarding to the poll function does seem reasonable to me. any thoughts on this?
Forwarding to the generated future SGTM.
Change:
for i in false..true {} //~^ ERROR the trait //~^^ ERROR the trait <ins> //~^^^ ERROR the trait </ins> // Unsized type. let arr: &[_] = &[1, 2, 3];

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?
Change:
let rem = n % 10; n /= 10; exponent += 1; <del> // round up last digit if rem >= 5 { </del> <ins> // round up last digit, round to even on a tie if rem > 5 || (rem == 5 && (n % 2 != 0 || subtracted_precision > 1 )) { </ins> n += 1; <ins> // if the digit is rounded to the next power // instead adjust the exponent if n.ilog10() > (n - 1).ilog10() { n /= 10; exponent += 1; } </ins> } } (n, exponent, exponent, added_precision)

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. --I tried this code: I expected this all to be fine. Instead, the final assertion fails, and the formatting is done like this in the final case: Not sure why 2 decimal places are returned, looks like a bug. This bug also exists in the beta or nightly versions, running in Rust Playground. Discussion: Edit: after looking around the compiler code for the first time I think the problem is somewhere in either or . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
No. The relevant code is actually the one for formatting integers in scientific notation, not floats. I. e. the relevant code is the code first introduced in As I mentioned in the linked URLO thread, I believe perhaps integer formatting in scientific notation should be fully identically behaving to the (seemingly "correct", and also historically older) formatting implementation for floats. This is a potential test we might want passing: but as of now, this kind of test fails in a lot of cases: In this test result, besides the behavior described in this issue, resulting in the wrong number of digits, there’s also the rounding behavior that is different between displaying floats and ints here. I’m not sure whether or not this difference is wanted. If it is_ wanted, it should be properly documented (on that note, I couldn’t easily find any documentation on the rounding used for floats, either), if it isn’t, it would be yet another issue or bug.
I would like to try and fix this bug claim
Change:
//! return. use crate::MirPass; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_index::vec::{Idx, IndexVec}; use rustc_middle::mir::coverage::*; use rustc_middle::mir::visit::{MutVisitor, MutatingUseContext, PlaceContext, Visitor};

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
// Skip lifetime parameters of the enclosing item(s) substs.as_closure().tupled_upvars_ty().visit_with(self); <del> for upvar_ty in substs.as_closure().upvar_tys() { upvar_ty.visit_with(self); } </del> substs.as_closure().sig_as_fn_ptr_ty().visit_with(self); }

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
does this still panic after ? That only merged a couple days ago so you'll need to update your version of nightly.
Hmm I checked and it does, and it also panics before. So probably unrelated? cc just in case
Note that this works fine on .
Sorry, I accidentally closed the issue. Yes, you are right. It still crashes on the latest nightly version. I have a cron job to update my rust version everyday.
I think we ended up (incorrectly) removing a check in We shouldn't be calling upvarsty if is . This is a separate issue than that was fixed in
claim
Change:
fn frequency() -> c::LARGE_INTEGER { static mut FREQUENCY: c::LARGE_INTEGER = 0; <del> static ONCE: Once = Once::new(); </del> <ins> static STATE: AtomicUsize = AtomicUsize::new(0); </ins> unsafe { <del> ONCE.call_once(|| { cvt(c::QueryPerformanceFrequency(&mut FREQUENCY)).unwrap(); }); FREQUENCY </del> <ins> // If a previous thread has filled in this global state, use that. if STATE.load(SeqCst) == 2 { return FREQUENCY; } // ... otherwise learn for ourselves ... let mut frequency = 0; cvt(c::QueryPerformanceFrequency(&mut frequency)).unwrap(); // ... and attempt to be the one thread that stores it globally for // all other threads if STATE.compare_exchange(0, 1, SeqCst, SeqCst).is_ok() { FREQUENCY = frequency; STATE.store(2, SeqCst); } return frequency; </ins> } }

Discussion:
I was trying to troubleshoot this issue: and eventually we figured out that on my machine parktimeout wasn't waking up. I wrote this simple test code which demonstrates the issue: Most of the time it will only print this: Every once in a while it will finish normally. This behavior happens on stable and nightly and I tried a handfull of stable versions all the way back to 1.12 and they all got stuck. Windows (both msvc and gnu appear to never get stuck (at least I couldn't reproduce the issue)). I was able to duplicate this an another mac as well (both running 10.14) If only a single thread is started (or the park happens on the main thread) then I can't reproduce. I'm on 10.14; uname:
This definitely seems broken. Here's dtruss output:
It's a deadlock on the ONCE here:
As a workaround, everything should work fine as long as you construct an at least once in your process before parking.
Doesn't seem to help :(
Oh right sorry, you actually have to subtract two Instants to force that Once to complete. If you instead do at the start of main, it prevents the deadlock.
Works perfectly now! Thanks!
Change:
<ins> error: structs are not allowed in struct definitions --> $DIR/issue-101540.rs:2:5 | LL |     struct S2 { |     ^^^^^^^^^ | = help: consider creating a new `struct` definition instead of nesting error: aborting due to previous error </ins>

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: <!-- The following is not always necessary. --Ideally the output should include a note informing the user that the declaration of another struct within a struct is not allowed and they should use separate declarations. (Wording might need a bit of tweaking). <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-terse
claim
Change:
fn visit_item(&mut self, item: &'hir hir::Item<'_>) { let name = match &item.kind { <del> hir::ItemKind::Macro(ref macro_def, _) => { // FIXME(#88038): Non exported macros have historically not been tested, // but we really ought to start testing them. let def_id = item.def_id.to_def_id(); if macro_def.macro_rules && !self.tcx.has_attr(def_id, sym::macro_export) { intravisit::walk_item(self, item); return; } item.ident.to_string() } </del> hir::ItemKind::Impl(impl_) => { rustc_hir_pretty::id_to_string(&self.map, impl_.self_ty.hir_id) }

Discussion:
At present, doctests aren't run on macros that are not annotated with . After , it will become possible to fix this problem. However, doing so will cause tests to run that were skipped previously to run, which will likely cause test failures and may mess up people's CI. It might be helpful to provide some form of warning period first. The relevant code is here: Fixing this issue technically just requires removing that special case. However, things are complicated by the fact that this will cause people's tests to suddenly fail. I'm not really sure how we should handle that. do you have any ideas? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also https://rust-
I think we should just change this; it's no different than in that the code was already broken before and we just didn't happen to run it. If you're really worried we can do a crater run but I would honestly be ok with just landing this.
label +E-easy +E-mentor
Looks like accidentally prevented these doctests from being run even if is passed :(
claim
FYI, rayon has an internal macro with an example that wasn't ready to be treated as a test: ... discovered by failing in a .
Hmm, I'm not even sure how to turn that into a working doctest, because the macro isn't exported. The in is also telling -- then what's the point?
Change:
When complete, `make install` will place several programs into `/usr/local/bin`: `rustc`, the Rust compiler, and `rustdoc`, the API-documentation tool. <del> 3. Read [The Rust Programming Language][trpl]. 4. Enjoy! </del> ### Building on Windows

Discussion:
There are a few issues of polish that I want to fix here: Although the installer internally supports multiple components there is no interface for actually selecting individual components. This is important because it allows to not install docs, which are 250 MB of the 50 MB install. Uninstallation can only be done through the original installer, which in many cases means the user is going to have to download the installer again. I want to put an uninstall script in the installation. This will require some refactoring and an upgrade of the installer manifest format.
This is a prereq for my plan to fix the .pkg uninstall issue
cc
cc
Change:
<del> Subproject commit 66df92aeba64547f3e9600635a30df34b12a11d8 </del> <ins> Subproject commit c8e3cfbdd997839c771ca32c7ac860fe95149a04 </ins>

Discussion:
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 compiler team prioritization.