jiebi/CodeConvo huggingface dataset:
Change:
// We do NOT compare the types for equality, because well-typed code can // actually "transmute" `&mut T` to `&T` in an assignment without a cast. assert!( <del> mir_assign_valid_types(src.layout, dest.layout), </del> <ins> mir_assign_valid_types(self.tcx.tcx, src.layout, dest.layout), </ins> "type mismatch when copying!nsrc: {:?},ndest: {:?}", src.layout.ty, dest.layout.ty,

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?
Change:
<ins> //! Test case for [#80737]. //! //! A SomeTrait that is implemented for `&mut T where T: SomeTrait` //! should not be marked as "notable" for return values that do not //! have bounds on the trait itself. //! //! [#80737]: https://github.com/rust-lang/rust/issues/80737 #![feature(rustdoc_internals)] #![no_std] #[doc(primitive = "reference")] /// Some useless docs, wouhou! /// /// We need to put this in here, because notable traits /// that are implemented on foreign types don't show up. mod reference {} // @has doc_notable_trait_mut_t_is_not_an_iterator/fn.fn_no_matches.html // @!has - '//code[@class="content"]' 'Iterator' pub fn fn_no_matches<'a, T: 'a>() -> &'a mut T { panic!() } </ins>

Discussion:
The "Notable traits" popup for [] shows notable traits for when it should show (or at least ): ! Note that this happens for other functions on . Another example is [] which shows when it should show . I'm not 100% sure this is a bug, but the behavior is definitely confusing: I'm not sure what the notable traits popup is referring to when it references an type parameter ( doesn't even appear in the file that is defined in...). []: []:
I think this is a duplicate of
Hmm, that seems possible. Wow, that issue is so old: it refers to ! Off-topic: is there a way to see what the docs from then look like?
Yes, you can manually type the version number in the URL:
Thanks! I forgot about that. However, I meant for the docs pre-1.0. Do you know of any way to view those?
Followup: 0.11.0 is the earliest version I could find docs for:
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. // Tests that an `impl Trait` that is not `impl Termination` will not work. fn main() -> impl Copy { } //~^ ERROR `main` has invalid return type `impl std::marker::Copy` </ins>

Discussion:
we’re stabilizing the combination of features that allows you to put in the return type of main as in . Amusing but unintended so it’s better to forbid this for now.
It's a bit late to change this. Does it cause any problem? AFAICT it just gives you a weird way to declare , but no new capability.
It doesn't give any new capability, I guess would even make sense in the return type of main. This bug could be considered a feature.
cc
Why this is an issue? returns and implements .
does not implement , which is required for the return type of .
Yea, it seems you can use any trait: Works on beta and nightly. So it'll probably work on this weeks stable You can't do anything stupid with this feature. The checks see right through the impl Trait to the real type (). I'd say adding a regression test that ensures that this corner case essentially ignores the anonymization of impl Trait is fine. We can add a deny by default lint that tells you that while this works, it's not pretty.
This seems fine to me and unless we care enough to stop the stable release we're not going to change this. cc though.
Hmm, I feel like we should just fix this. I doubt there are a lot of people taking advantage of it. I can put up some mentoring instructions. We can do a warning period if needed.
Fwiw I tried fixing by doing and got ICEs and stack oveflows which I couldn't debug so I gave up.
Hmm, I don't understand the stack overflows, but I think I would expect that patch to have no effect. The cause of the bug is that we are "instantiating" the impl Trait, here: In the process, we shadow the "original" with a new variable . This new will contain an inference variable used to find the "hidden" type underneath the . Later on, when we add the obligation that (where is the return type), we use this new variable: If we used the original (currently shadowed) , I think it would permit you to use but not other impl traits. (That said, it wouldn't be the end of the world if we just let this go, I suppose.)
As far as I understand we don't want to block 1.26 stable on this, right?

In that case I think we should go with a lint instead of an hard error, since both of the features will be stabilized now.
I probably borked the state of my clone or something. Thanks for the explanation, makes perfect sense, will make a patch.
Change:
<ins> error[E0271]: type mismatch resolving `<() as Array>::Element == &()` --> $DIR/issue-44153.rs:18:5 | LL |     fn visit() {} |     ---------- required by `Visit::visit` ... LL |     <() as Visit>::visit(); |     ^^^^^^^^^^^^^^^^^^^^ expected (), found &() | = note: expected type `()` found type `&()` = note: required because of the requirements on the impl of `Visit` for `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
break; } var entry = expected[key]; <ins> if (exact_check == true && entry.length !== results[key].length) { error_text.push(queryName + "==> Expected exactly " + entry.length + " results but found " + results[key].length + " in '" + key + "'"); } </ins> var prev_pos = -1; for (var i = 0; i < entry.length; ++i) { var entry_pos = lookForEntry(entry[i], results[key]);

Discussion:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.
Change:
data-theme-dark-css="{{files.theme_dark_css}}" {#+ #} data-theme-ayu-css="{{files.theme_ayu_css}}" {#+ #} > {# #} <del> </div> {# #} </del> <script src="{{static_root_path|safe}}{{files.storage_js}}"></script> {# #} {% if page.css_class.contains("crate") %} <script defer src="{{page.root_path|safe}}crates{{page.resource_suffix}}.js"></script> {# #}

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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.
Change:
<ins> // check-pass: this used to be a stack overflow because of recursion in `usefulness.rs` macro_rules! long_tuple_arg { ([$($t:tt)*]#$($h:tt)*) => { long_tuple_arg!{[$($t)*$($t)*]$($h)*} }; ([$([$t:tt $y:tt])*]) => { pub fn _f(($($t,)*): ($($y,)*)) {} } } long_tuple_arg!{[[_ u8]]########## ###} fn main() {} </ins>

Discussion:
The following macro generates a function with 4096 entries in the tuple. () It’s explicitly a stack overflow on stable and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety. label I-crash, T-compiler
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Digged a bit, this is indeed a stack overflow. Since rustc uses stacker, if we moved to a segemented stack instead of the native stack, std didn't know this is a stack overflow and so it appears as segfault instead. The root cause is that uses recursion.
Change:
packages: &[], features: None, manifest_path: None, <ins> filters: &[], </ins> }, Test { name: "tokei",

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
<del> Subproject commit 1e05dffbeeb80ba61bf59cc63b222d538d7825ed </del> <ins> Subproject commit 3001c75a1d2a81d2a76bef139c69387cb2ebb820 </ins>

Discussion:
This is a tracking issue for the feature gate, tracking the stabilization of the bittest Intel intrinsics - see .
I think it'd be reasonable to stabilize these at this point. 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] [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. The RFC will be merged soon.
Change:
<ins> -include ../tools.mk all: $(RUSTC) foo.rs $(RUSTC) bar.rs --emit dep-info grep "rustc-macro source" $(TMPDIR)/bar.d && exit 1 || exit 0 </ins>

Discussion:
Noticed it causing issues with cargo as it uses and then parses the files as part of the fingerprinting process. It seems every instance of macro generated code (e.g. via serde_derive) creates a entry into this file which when cargo tries to look up it can't find. Cargo issue:
Added this to the macros 1.1 tracking issue (I consider this a blocker for stabilization)
Change:
process::Command, }; <del> use crate::core::build_steps::dist::distdir; </del> use crate::core::builder::Builder; <ins> use crate::core::{build_steps::dist::distdir, builder::Kind}; </ins> use crate::utils::channel; use crate::utils::helpers::t;

Discussion:
Right now when doing a local , we first compress the artifacts with max compression ratio, just to immediately unpack them again when installing them to disk. Making the compression level less aggressive or skipping it altogether can probably save 5-10 minutes on an x.py install. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc You probably want to use the gzip'd artifacts which are less intensely compressed.
tbh it seems strange that we're compressing these at all - why not put them into an uncompressed .tar archive when using ?
or even better, copy them directly from the build directory to the install directory without going through a .tar archive first.
claim
Skipping the compressions and archiving in favor of directly copying the artifacts seems like a reasonable solution for . But it requires significant changes to how we currently handle . I'm planning to do a comprehensive review on bootstrapping from all angles(including T-bootstrap issues) and make a roadmap for future development. To avoid conflicts(e.g, if we have improvement ideas on dist/install modules, implementing this might increase the technical debt which will require more effort from the team), I will postpone this task for now and re-prioritize it once we have organized the plans.
Change:
<ins> error[E0491]: in type `&'a &'b ()`, reference has a longer lifetime than the data it references --> $DIR/reference-outlives-referent.rs:7:18 | LL | const Q<'a, 'b>: &'a &'b () = &&(); |                  ^^^^^^^^^^ | note: the pointer is valid for the lifetime `'a` as defined here --> $DIR/reference-outlives-referent.rs:7:9 | LL | const Q<'a, 'b>: &'a &'b () = &&(); |         ^^ note: but the referenced data is only valid for the lifetime `'b` as defined here --> $DIR/reference-outlives-referent.rs:7:13 | LL | const Q<'a, 'b>: &'a &'b () = &&(); |             ^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0491`. </ins>

Discussion:
The code below leads to the following compiler panic <details<summaryfull stderr</summary</details<details<summary<coderustc -Vv</code</summary</details label -needs-triage C-bug I-ICE T-compiler F-genericconstitems requires-incomplete-features claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
Change:
} if v.iter().any(|i| i.inner_impl().trait_.is_some()) { <del> if let Some(impl_) = v .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cache) == cx.cache.deref_trait_did) { sidebar_deref_methods(cx, out, impl_, v); } </del> let format_impls = |impls: Vec<&Impl>| { let mut links = FxHashSet::default();

Discussion:
For example, I would much rather have the documentation for my crate Staticvec look , as opposed to pulling in the docs for every single slice method Edit: Some additional thoughts: even if this isn't possible for some reason, it would almost certainly be better to have the crate-native "Trait Implementations" section appear before the "Methods From Deref" section does, since "Trait Implementations" will pretty much always be describing things that are unique to the crate being documented and so actually directly relevant a good idea might also be to have the "Methods From Deref" header amount to a clickable link that redirects to the actual primary docs for whatever is being derefed to in any case where it is being left empty, if that is still possible
Are there any details on when precisely this changed, also? I've noticed that even though the auto-generated docs on previously left the "Methods From Deref" section empty for user-submitted crates, it was seemingly always filled out for stuff like the official docs for , so presumably there has always been some kind of way of controlling 's behaviour in this regard, unless I'm missing something.
Yes, it was changed intentionally in and mentioned in the release notes: Vec derefs directly to slice - maybe the user crates you're talking about always deref to Vec?
:+1: I like this idea. Hmm, I'm a little concerned the methods will be harder to find that way. We get a lot of complaints that the "Trait Implementations" section is hard to read because you have to click on the name of the trait to see what methods are available.
Yeah, that makes sense. Honestly just showing before in any case where both exist would likely pretty much cover the kind of thing I was mostly concerned about by itself anyways.
Are you interested in making a PR for that? I think it would be as simple as moving after :)
Sure, I'll take a look at it tomorrow.
Got busy with some other stuff, but I've now opened a PR that make those changes, which do accomplish what you thought they would.
Change:
largest_niche, size, align, <del> })); </del> <ins> }); </ins> } } }

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
//~^ NOTE this pattern matches any value anything => () //~^ ERROR unreachable pattern <ins> //~^^ NOTE this is an unreachable pattern </ins> }; // `_` need not emit a note, it is pretty obvious already. let t = (Var1, Var1);

Discussion:
From: src/test/compile- We need to add a span_label to update E0001 from: To:
Taking it
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> 2016-12-08 </del> <ins> 2016-12-16 </ins>

Discussion:
Works fine with : This is a bug in LLVM () that has already been fixed in . We only have to backport the fix. cc
Seeing the reproduction involves assembly and jumping to a label that hasn’t been passed as an input for the asm!, I do not think this deserves a backport.
I meant backporting/cherry-picking the upstream fix into our LLVM fork; not a "beta-backport". People that use the targets make pretty much exclusive use of the nightly channel (because Xargo, unstable features, etc.) so whether a fix makes it faster to the stable/beta channel doesn't really make much difference to us. Honest question: How does one pass a function to with the goal of using it as a label? And does that handle the mangling of the function?
There’s no support for doing that directly in LLVM sadly, mostly because this is not a very desired feature; and you can work around the issue with some indirection, which not only handles mangling but also any relocation business you might have going on (pardon my x86): compiles to code like this (PIC) or in static relocation mode.
Clever. The ARM asm parser doesn't seem to like the dereference though:
to branch to an address in a register can do but if you want to branch to a label you need an integer constant constraint.
Thanks, That works nicely and will let me hide more symbols in some crates like f3 . (Using "b $0" with the thumbv6m target still needs though)
Change:
mod job; #[cfg(parallel_compiler)] <del> pub use self::job::deadlock; </del> <ins> pub use self::job::break_query_cycles; </ins> pub use self::job::{ print_query_stack, report_cycle, QueryInfo, QueryJob, QueryJobId, QueryJobInfo, QueryMap, };

Discussion:
I noticed that when parallel rustc panics due to deadlock, it would say instead of . Is this intended?
Hm, I did recently land but I'm not sure if it would cause this issue. It should only affect threads that Rust doesn't create itself and in any case it switches the default name from (which gets rendered as ) to the OS thread name (if available). So if anything I'd have thought it would have the opposite effect. Though maybe there's something about parallel's deadlocks I'm missing.
I think you're good since the problem is older than your pr :D
Oh good! I mean bad, but I was dreading a very long debugging session
well, if you feel bored or something.... :upsidedownface:
Serial rustc creates a single thread called rustc. I assume parallel rustc just doesn't name its rayon threads, no debugging session ahead.
We create a new thread to look for query cycles, it's unnamed at the moment and that's where the panic happens.
Change:
#![feature(never_type)] use std::mem::size_of; <ins> use std::num::NonZeroU8; </ins> struct t {a: u8, b: i8} struct u {a: u8, b: i8, c: u8}

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.