jiebi/CodeConvo huggingface dataset:
Change:
<ins> // edition:2018 // #70935: Check if we do not emit snippet // with newlines which lead complex diagnostics. use std::future::Future; async fn baz<T>(_c: impl FnMut() -> T) where T: Future<Output=()> { } fn foo(tx: std::sync::mpsc::Sender<i32>) -> impl Future + Send { //~^ ERROR: future cannot be sent between threads safely async move { baz(|| async{ foo(tx.clone()); }).await; } } fn bar(_s: impl Future + Send) { } fn main() { let (tx, _rx) = std::sync::mpsc::channel(); bar(foo(tx)); } </ins>

Discussion:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.
Change:
use super::ResolverAstLoweringExt; use rustc_ast::visit::{self, BoundKind, LifetimeCtxt, Visitor}; use rustc_ast::{GenericBounds, Lifetime, NodeId, PathSegment, PolyTraitRef, Ty, TyKind}; <del> use rustc_hir::def::LifetimeRes; </del> <ins> use rustc_hir::def::{DefKind, LifetimeRes, Res}; </ins> use rustc_middle::span_bug; use rustc_middle::ty::ResolverAstLowering; use rustc_span::symbol::{kw, Ident};

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
This is not an RPITIT bug, for the record.
Change:
use rustc_hir as hir; use rustc_hir::def_id::DefId; use rustc_hir::lang_items::LangItem; <ins> use rustc_infer::traits::TraitEngineExt as _; </ins> use rustc_middle::ty::fold::TypeFoldable; use rustc_middle::ty::subst::{InternalSubsts, SubstsRef}; use rustc_middle::ty::visit::TypeVisitable; <del> use rustc_middle::ty::{self, GenericParamDefKind, ToPredicate, Ty, TyCtxt, VtblEntry}; </del> <ins> use rustc_middle::ty::{ self, DefIdTree, GenericParamDefKind, Subst, ToPredicate, Ty, TyCtxt, TypeSuperVisitable, VtblEntry, }; </ins> use rustc_span::{sym, Span}; use smallvec::SmallVec;

Discussion:
Found in [this topic] on URLO. It shows the method on the page for . This is misleading, because you can't actually call that method, because . [this topic]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The same issue with and . do you know how to exclude these options from hashmap? I'm still digging with it, if hashmap has this kind of issue, other data structures maybe have similar kind of issue. I think we need to check the trait bounds when generating the doc.
I expect you want to do it while — turning the rustc IR into rustdoc's own IR — or earlier. Doing it later would mean reimplementing parts of rustc's type checker using rustdoc's IR, and nobody wants to do that.
For the record I was working on this, sorry for not claiming this... Anyways, let me know if you don't get around to this, and I'll pick it back up :smile_cat: . Seems like you've claimed a few issues in the past hours so not sure which ones you've gotten started with.
I haven't started this one, released it, please go ahead. It's funny and also helpful to learn some Rust internals, I'm starting with some trivial fixes
Thank you Sorry for the mistake, and I am excited for you to get involved more in the compiler :) claim
This is a dupe of
Uh, sorry, actually not a dupe. That's impl level, this is method level. I think there were legitimate concerns with hiding whole impls in that other issue. Reopening this, andf I'll probably solve this first.
Change:
let names = resolutions.iter().filter_map(|(&(ref i, _), resolution)| { if *i == ident { return None; } // Never suggest the same name match *resolution.borrow() { <del> NameResolution { binding: Some(_), .. } => Some(&i.name), </del> <ins> NameResolution { binding: Some(name_binding), .. } => { match name_binding.kind { NameBindingKind::Import { binding, .. } => { match binding.kind { // Never suggest the name that has binding error // i.e. the name that cannot be previously resolved NameBindingKind::Def(Def::Err) => return None, _ => Some(&i.name), } }, _ => Some(&i.name), } }, </ins> NameResolution { single_imports: SingleImports::None, .. } => None, _ => Some(&i.name), }

Discussion:
Sometimes it is very useful when rustc figures out that the faulty module use you just made is probably just a typo and directs you a potential match (thanks for that!). However it also directs you to potential matches which haven't been found either in certain cases, for example compiling currently (2016-11-28) yields with both stable and nightly the following output: While this is merely a suggestion displayed and shouldn't cause any harm at all maybe it might still be worth to check if what is suggested was actually found in the current scope. Or would that be too expensive (e.g. overhead in tracking what was already successfully imported and what not) and is thus left as is by design?
Is this easy to fix ? If so - maybe worth marking as so and mentioning on Rust Weekly ?
Yeah, I believe this can be fixed by replacing with .
I think I can take this, if it hasn't been worked on so far!
go for it
How can I assign myself?
Not sure if you can via github, due to permissions, but you can just start working on it :) There's a trace in the comments, anyone looking for more work would see them hopefully here in this issue.
Change:
&'c &'b str [char; N] char <del> pattern::MultiCharEqPattern<C> </del> = note: required because of the requirements on the impl of `Pattern<'_>` for `u8` 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. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
document.onkeydown = handleShortcut; document.onclick = function(ev) { if (hasClass(ev.target, 'collapse-toggle')) { <del> collapseDocs(ev.target); </del> <ins> collapseDocs(ev.target, "toggle"); </ins> } else if (hasClass(ev.target.parentNode, 'collapse-toggle')) { <del> collapseDocs(ev.target.parentNode); </del> <ins> collapseDocs(ev.target.parentNode, "toggle"); </ins> } else if (ev.target.tagName === 'SPAN' && hasClass(ev.target.parentNode, 'line-numbers')) { var prev_id = 0;

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
done < "${CFG_SRC_DIR}/${CFG_LIBDIR_RELATIVE}/rustlib/manifest.in" # Sanity check: can we run the installed binaries? <ins> # # As with the verification above, make sure the right LD_LIBRARY_PATH-equivalent # is in place. Try first without this variable, and if that fails try again with # the variable. If the second time tries, print a hopefully helpful message to # add something to the appropriate environment variable. </ins> if [ -z "${CFG_DISABLE_VERIFY}" ] then msg "verifying installed binaries are executable" <del> "${CFG_PREFIX}/bin/rustc" --version > /dev/null </del> <ins> "${CFG_PREFIX}/bin/rustc" --version 2> /dev/null 1> /dev/null </ins> if [ $? -ne 0 ] then <del> ERR="can't execute installed rustc binary. " ERR="${ERR}installation may be broken. " ERR="${ERR}if this is expected then rerun install.sh with `--disable-verify` " ERR="${ERR}or `make install` with `--disable-verify-install`" err "${ERR}" </del> <ins> export $CFG_LD_PATH_VAR="${CFG_PREFIX}/lib":$CFG_OLD_LD_PATH_VAR "${CFG_PREFIX}/bin/rustc" --version > /dev/null if [ $? -ne 0 ] then ERR="can't execute installed rustc binary. " ERR="${ERR}installation may be broken. " ERR="${ERR}if this is expected then rerun install.sh with `--disable-verify` " ERR="${ERR}or `make install` with `--disable-verify-install`" err "${ERR}" else echo echo "    please ensure '${CFG_PREFIX}/lib' is added to ${CFG_LD_PATH_VAR}" echo fi </ins> fi fi

Discussion:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)
Change:
<ins> // edition: 2021 use std::future::Future; async fn bop() { fold(run(), |mut foo| async move { &mut foo.bar; }) } fn fold<Fut, F, U>(_: Foo<U>, f: F) where F: FnMut(Foo<U>) -> Fut, { loop {} } struct Foo<F> { bar: Vec<F>, } fn run() -> Foo<impl Future<Output = ()>> { //~^ ERROR type annotations needed loop {} } fn main() {} </ins>

Discussion:
https://crater- https://crater- https://crater-
Might be related to
I've tried the first 2 crates (bonedaddy.ellidri and edu-sync), they compile on the current stable fail to compile on beta and nightly. Provisionally assigning P-high waiting for more investigation (). label -I-prioritize +P-high +T-compiler
bisected to commit , where in this commit originates the issue: Regression in i.e. rollup PR (Implement proposed API for ) (Simplify computation of killed borrows) (More nits) (add note for non-exhaustive matches with guards) (Fix invalid HTML DIV tag used in HEAD) (add myself to review for t-types stuff) label -e-needs-bisection
Bisection probably leads to cc TIL to look at the results, they help getting more context. They told me tha PR is actually commit
I'll take a look at this after RustConf.
Is it possible the bisection contained an error? I'm not seeing any possible connection. The errors seem unrelated, is not used anywhere in my PR, and is not even present in any of the three linked logs.
Ok, I give up on reproducing using the crate (in the latest nightlies the error changed, I can't track the original error anymore). So I've started again using the crate I now have a stable reproducible. I am now a bit more confident the regression is in (specifically ) cc (I see in that patch some code that is in the stacktraces). sorry for the ping and thanks for pointing me into the right direction :)
No worries! Someone mentioned that it may have been incorrect at RustConf, but I wanted to have a chance to look into it myself before saying anything. I'll be unsubscribing from this issue; please ping if something needs my attention :)
small, but not yet minimal repro. Should be good enough for the test suite. I'm looking into a fix now.
I reverted all changes from and it does not appear to change behaviour. trying a local bisect on the minimal repro. edit: hmm weird, it also points to that PR. Trying again edit2: ok now it works, weird
Change:
{ let e = E::C; assert_eq!(e as u32, 2); <del> assert_eq!(FLAG.load(Ordering::SeqCst), 0); </del> <ins> assert_eq!(FLAG.load(Ordering::SeqCst), 1); </ins> } assert_eq!(FLAG.load(Ordering::SeqCst), 1); }

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.
Change:
let reachable_context = ReachableContext::new(tcx, method_map); // Step 1: Seed the worklist with all nodes which were found to be public as <del> //         a result of the privacy pass </del> <ins> //         a result of the privacy pass along with all local lang items. If //         other crates link to us, they're going to expect to be able to //         use the lang items, so we need to be sure to mark them as //         exported. let mut worklist = reachable_context.worklist.borrow_mut(); </ins> for &id in exported_items.iter() { <del> let mut worklist = reachable_context.worklist.borrow_mut(); </del> worklist.get().push(id); } <ins> for (_, item) in tcx.lang_items.items() { match *item { Some(did) if is_local(did) => { worklist.get().push(did.node); } _ => {} } } drop(worklist); </ins> // Step 2: Mark all symbols that the symbols on the worklist touch. reachable_context.propagate();

Discussion:
Fails to compile with linking errors:
Either this or require that they are .
I think I disagree. Lang items should be public - for the most part they are used just like any other item.
Though there is some appeal to being able to hide lang items that aren't part of the public API.
I don't think we'll ever expect someone to use a lang item directly, and for an executable there's no need for lang items to be public, there's not even a need for them to be reachable really. I suppose we could just require that libraries have public lang items? Regardless, this seems like kinda a corner case to me because there's not that much interaction with lang items.
I'm actually surprised that this example compiled. I guess something in rustc was ignoring visibility when encoding calls to .
Change:
RawTable { capacity: capacity, size:     0, <del> hashes:   Unique(hashes), </del> <ins> hashes:   hashes, </ins> marker:   marker::CovariantType, } }

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
<ins> // run-rustfix fn main() { let x = 42; //~ HELP let _y = x; //~ ERROR } </ins>

Discussion:
Variables can be marked as unused by prepending with an underscore. If at some point such a variable is used again, the compiler suggests to name the use , even though every single time I have encountered this, what I wanted is to change the definition of to . () Errors:
I feel we should have a counterpart to the unused lint that checks for variables that are used but use the unused bar convention. That wouldn't be useful for the case presented here where you're using an unused bar for the first time, but seems like a reasonable addition.
Such a lint is problematic within macros or other compiler-expanded code, since it's a common pattern to work around not knowing if there are any uses by naming the variables appropriately (for an example look at the loop lowering code)
I agree but I'm pretty sure that most lints should ignore code with spans in macro context already.
Hi, I'd like to work on this!
sorry for not responding earlier. I only have very broad instructions right now, but don't hesitate to ask here or on the stream on zulip if you need more help. the place where the diagnostic "a local variable with a similar name exists" is emitted note that the "local variable" part may be a placeholder and the rest of the string might be broken across multiple lines if that place has more info than just the name of the local variable not, add a to whatever datastructure holds the name I'm not sure how the name is obtained right now, but there should be a way to get at the there, too. E.g. if the name is an , then it has a field. emitting the "similar name" diagnostic, first check whether the suggested name starts with an underscore, but the name used in the code does not that chek fails, keep the old message , emit the suggestion not on the span that it is currently emitted on, but on the definition span (and change the suggestion to remove the underscore)
Hi I've already done most of that :) I think I'll have a working PR next week.
I can work on this if you guys are caught up with something else :)
sure. Just once you start working on it. Maybe you can even get the WIP branch from fork
Change:
<ins> // Copyright 2014-2015 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. pub fn cmd(name: &str) -> String { if cfg!(windows) { format!("{}.bat", name) } else { name.to_string() } } </ins>

Discussion:
After following the steps in the , running gives the following output: See for discussion. believes it to be an issue with invoking without enabling shell expansion.
Invoking fixes the error above, but another error pops up (see below).
Here is a workaround: instead of invoking , invoke . (Wow, it takes a long time—90 seconds until it fails in optimisation for a very basic thing seems inordinate!)
Same, when trying to invoke given command directly, getting instead:
Ah, this seems to be rather related to
Indeed. PR is work in progress. Also emscripten 1.35.0 (latest pre-build binary) does not work (see llvm assertion above). I haven't had the chance to try out emscripten 1.37.0 ()
Yep, that's what was suggested in that other issue and I can confirm it works.
For the sake of completeness, I finally had the time to test everything. This works for windows: Get emscripten 1.37.0: VS 2013 Community (required by emscripten) Rewire rustc to : Workaround for rust 1.14: Fix: PR I guess should check for a minimal required emscripten version, but this is probably out of scope.
Thanks for the investigations and the patch
Looks like the fix is merged.
I get the same error. Unless I run rustc from the same cmd windows I used to run emsdk activate. Running emsdk activate with --global doe not seem to change anything. This may just be how it is intended to work.
Did you run emsdk activate --global in elevated cmd? That's what it would take for it to work and permanently store generated environment variables in registry.
Change:
/// Given an impl trait in trait `opaque_ty_def_id`, create and return the corresponding /// associated item. query associated_type_for_impl_trait_in_trait(opaque_ty_def_id: LocalDefId) -> LocalDefId { <del> desc { |tcx| "creates the associated item corresponding to the opaque type `{}`", tcx.def_path_str(opaque_ty_def_id.to_def_id()) } </del> <ins> desc { |tcx| "creating the associated item corresponding to the opaque type `{}`", tcx.def_path_str(opaque_ty_def_id.to_def_id()) } </ins> cache_on_disk_if { true } }

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
// Check if a landing pad block exists; if not, create one. { let mut scopes = self.scopes.borrow_mut(); <del> let last_scope = scopes.get().mut_last(); </del> <ins> let last_scope = scopes.get().mut_last().unwrap(); </ins> match last_scope.cached_landing_pad { Some(llbb) => { return llbb; } None => {

Discussion:
changed the , and methods of vectors to return an Option instead of failing on empty vectors. These methods should probably get the same change, to be consistent - - -
I'll try to fix this!