jiebi/CodeConvo huggingface dataset:
Code change:
#[stable(feature = "rust1", since = "1.0.0")] pub trait PhantomFn<A:?Sized,R:?Sized=()> { } <del> /// `PhantomData` is a way to tell the compiler about fake fields. /// Phantom data is required whenever type parameters are not used. /// The idea is that if the compiler encounters a `PhantomData<T>` /// instance, it will behave *as if* an instance of the type `T` were /// present for the purpose of various automatic analyses. </del> <ins> /// `PhantomData<T>` allows you to describe that a type acts as if it stores a value of type `T`, /// even though it does not. This allows you to inform the compiler about certain safety properties /// of your code. /// /// Though they both have scary names, `PhantomData<T>` and "phantom types" are unrelated. 👻👻👻 </ins> /// /// # Examples /// /// When handling external resources over a foreign function interface, `PhantomData<T>` can <del> /// prevent mismatches by enforcing types in the method implementations, although the struct /// doesn't actually contain values of the resource type. </del> <ins> /// prevent mismatches by enforcing types in the method implementations: </ins> /// /// ``` /// # trait ResType { fn foo(&self); };

Related discussion:
text: (I imagine that many external libs with data structures have had to insert 's since the change... meaning they were likely incorrect too.)
Code change:
use std::fmt::{Debug, Display}; <del> #[marker] trait Marker {} </del> <ins> #[marker] trait Marker {} </ins> impl<T: Debug> Marker for T {} impl<T: Display> Marker for T {}

Related discussion:
text: Not sure if we have a test for the following and rust #![feature(markertraitattr)] #[marker] trait Marker {} impl Marker for &' () {} impl Marker for &' () {} If not, we need to add them, since they would be important for special casing during canonicalization. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can help add this test if needed. (Did not rustbot claim so as to not remove lcnr from assignee)
Sure :) would help out if nothing else
assign Rageking8
Error: Parsing assign command in failed: ...' Rageking8' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
assign
label +F-markertraitattr In case this needs to be indexed in the future.
Code change:
<del> Subproject commit 4cf36f285084f8f841f3cff7b29d44b1d95ee1dd </del> <ins> Subproject commit 54bbbd13ac532deed80416295a224ce12547a40c </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!
Where can I learn more about how this check is done? I just built stage 1 compiler with current master, and I was able to build miri with .
I'm guessing one of the tests is failing because it now needs a . The failure should be hidden somewhere in the logs of the runner:
should fix tihs.
Ah, so the problem is in one of the tests.. I only checked building.
usually, should let you run the tests, but this is currently broken by
Code change:
assert_eq!(c.stream_position()?, 8); assert_eq!(c.stream_position()?, 8); <ins> c.rewind()?; assert_eq!(c.stream_position()?, 0); assert_eq!(c.stream_position()?, 0); </ins> Ok(()) }

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for the convenience method . [x] Implementation: [x] Final commenting period (FCP) [x] Stabilization PR: <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .
Code change:
assert_eq!(c.stream_position()?, 8); assert_eq!(c.stream_position()?, 8); <ins> c.rewind()?; assert_eq!(c.stream_position()?, 0); assert_eq!(c.stream_position()?, 0); </ins> Ok(()) }

Related discussion:
text: :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.
I missed it completely in nigthlies sadly, else I would have proposed it returns the of the old offset, because currently it cannot replace , only the form without assignement.
Code change:
<ins> // edition: 2021 use std::collections::HashMap; use std::future::Future; use std::pin::Pin; pub trait Trait { fn do_something<'async_trait>(byte: u8) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>; } pub struct Struct; impl Trait for Struct { fn do_something<'async_trait>(byte: u8) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>> { Box::pin( async move { let byte = byte; let _: () = {}; }) } } pub struct Map { map: HashMap<u16, fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>>>, } impl Map { pub fn new() -> Self { let mut map = HashMap::new(); map.insert(1, Struct::do_something); Self { map } //~^ ERROR mismatched types } } fn main() {} </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. --<!-- 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
Is this related to ?
Nope
Ooh I misread the Typerror ice, my bad :upsidedownface:
No big deal, this has to do with a lock (well, refcell) being held in hir typeck, if you're curious
Code change:
<ins> // build-pass // compile-flags: -O // min-llvm-version: 14.0.5 // needs-asm-support // only-x86_64 // only-linux // regression test for #96797 #![feature(asm_sym)] use std::arch::global_asm; #[no_mangle] fn my_func() {} global_asm!("call_foobar: jmp {}", sym foobar); fn foobar() {} fn main() { extern "Rust" { fn call_foobar(); } unsafe { call_foobar() }; } </ins>

Related discussion:
text: This code will fail to link because is merged into . Since global asms in LLVM can't reference symbols natively, we currently will add the mangled name to the string and pass it to LLVM. To prevent the file being optimized away, we add it to . A few issues exist: does not handle these functions specially, and therefore above is considered as internal function and have attribute attached. LLVM believes that it is allowed to merge internal functions into an exported function despite present in . I think LLVM should be allowed to this because we emit the internal linkage, and from my understanding renaming a local symbol should probably be allowed. argues otherwise and says that shouldn't touch the symbol. The symbols are , but it wouldn't show up as used in the exported symbol list, so it can still be stripped while doing LTO. We should do the following: [ ] Ensure that these functions are not emitted with internal linkage [ ] Ensrue that the functions used will be marked as used in and thus reach the linker/LTO. [ ] Ask LLVM to clarify the behaviour of combining + . cc label: +A-inline-assembly +F-asm This will block
I think should be enough to ensure that the symbol reaches the linker even through LTO. So really the only thing to do is change the symbol visibility. This isn't ideal though since we don't need this symbol to be exported outside the current compilation unit, it's just that LLVM is unable to see the use of the symbol.
It could be argued that this is actually an LLVM bug since linkage is supposed to preserve the symbol name in the object file:
I had to have to prevent from being thrown away.
Anyway, the biggest issue is the linkage, which is wrong anyway if the global asm and the referenced symbol are not in the same CGU. Given that currently both and the linkage computation comes from the same source of truth , a potential fix should be able to address all issues simultaneously.
This is fixed by . The proper behavior for LLVM is still unclear, but at least fixes the immediate issue since those symbols now have external linkage. This is a separate issue, but I think the proper way to fix this is to ensure that the itself reaches the linker. The problem here is that if there are no symbols to pull in the object file containing a from an archive then that will not be linked into the final binary.
Code change:
<ins> // build-pass // compile-flags: -O // min-llvm-version: 14.0.5 // needs-asm-support // only-x86_64 // only-linux // regression test for #96797 #![feature(asm_sym)] use std::arch::global_asm; #[no_mangle] fn my_func() {} global_asm!("call_foobar: jmp {}", sym foobar); fn foobar() {} fn main() { extern "Rust" { fn call_foobar(); } unsafe { call_foobar() }; } </ins>

Related discussion:
text: I think we can fix this by inserting a dummy symbol in the and then including that symbol in the synthetic object file from .
It's of a different cause, but will have the same effect. I prefer to have it tracked in the same issue (but different work items). The problem is two fold. For the normal non-LTO linking, what you described is sufficient. The major issue is LTO. Because LTO works on IR but not binary, it doesn't know if a symbol is being used in . We need to pass a list of symbols to LLVM to ensure they are kept. Currently this includes all exported and symbols, but it also needs to include all symbols referenced by .
Do you have an example demonstrating the LTO related issue? Optimizations during LTO cannot remove symbols from yet, since as you describe the references to those symbols from the inline assembly are still opaque to it. For example, the internalize pass in LLVM comments:
That comment suggests that even with internal visibility, LLVM isn't supposed to delete a symbol that is used by . So perhaps the issue really is in the MergeFunctions pass which should be fixed to preserve a symbol alias if that symbol is used by .
Here's my attempt at a fix in LLVM, but I'm not too happy about the code. It could use some review by someone more familiar with LLVM.
Code change:
// These are either the stage0 downloaded binaries or the locally installed ones. pub initial_cargo: PathBuf, pub initial_rustc: PathBuf, <ins> pub initial_cargo_clippy: Option<PathBuf>, </ins> #[cfg(not(test))] initial_rustfmt: RefCell<RustfmtState>,

Related discussion:
text: I'm pretty sure it is possible to set custom paths for , & in but not for clippy.
label +T-bootstrap
Code change:
<ins> error: expected item, found `;` --> $DIR/missing-main-issue-124935-semi-after-item.rs:5:1 | LL | ; | ^ help: remove this semicolon | = help: function declarations are not followed by a semicolon error: aborting due to 1 previous error </ins>

Related discussion:
text: Tested on nightly and stable. The second diagnostic is strange. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-diagnostics S-has-mvce
claim
any idea why rustbot ignored me?
Just guessing, the missing + for S-has-mcve maybe?
Oops, this should'nt've been closed.
Code change:
fn visit_async_fn( &mut self, id: NodeId, <del> async_node_id: NodeId, return_impl_trait_id: NodeId, </del> name: Name, span: Span, <del> visit_fn: impl FnOnce(&mut DefCollector<'a>) </del> <ins> header: &FnHeader, generics: &'a Generics, decl: &'a FnDecl, body: &'a Block, </ins> ) { <ins> let (closure_id, return_impl_trait_id) = match header.asyncness { IsAsync::Async { closure_id, return_impl_trait_id, } => (closure_id, return_impl_trait_id), _ => unreachable!(), }; </ins> // For async functions, we need to create their inner defs inside of a // closure to match their desugared representation. let fn_def_data = DefPathData::ValueNs(name.as_interned_str()); let fn_def = self.create_def(id, fn_def_data, ITEM_LIKE_SPACE, span); return self.with_parent(fn_def, |this| { this.create_def(return_impl_trait_id, DefPathData::ImplTrait, REGULAR_SPACE, span); <del> let closure_def = this.create_def(async_node_id, </del> <ins> visit::walk_generics(this, generics); visit::walk_fn_decl(this, decl); let closure_def = this.create_def(closure_id, </ins> DefPathData::ClosureExpr, REGULAR_SPACE, span); <del> this.with_parent(closure_def, visit_fn) </del> <ins> this.with_parent(closure_def, |this| { visit::walk_block(this, body); }) </ins> }) }

Related discussion:
text: Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:
Code change:
<ins> // Copyright 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. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>

Related discussion:
text: Mm, we have "method macros" but now there are other things that can go in a trait.
Seems to be fixed by , but I don't see tests for it specifically, so I guess this needs tests.
Code change:
<ins> // Copyright 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. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>

Related discussion:
text: Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.
Code change:
<ins> // Copyright 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. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>

Related discussion:
text: RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.
Code change:
<ins> // Copyright 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. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>

Related discussion:
text: AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .
Code change:
<ins> // Copyright 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. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>

Related discussion:
text: I got this while trying to implement something similar to a FromStr trait and tried to rely on a lot of inferencing when calling it. I can try to extract a standalone example if needed.
This ICE is also producible by trying to refer to an associated type that's never defined. is accepted by the compiler when it clearly should not be - what on earth is ? The following and code cases the same ICE. Here's the stack trace:
Code change:
<ins> // Copyright 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. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>

Related discussion:
text: I get the ICE below when I compile this fragment of code: The above structs are defined here: The above fragment is part of That crate depends on And that crate requires erlang-17.4 to be installed.
A minimal program to demonstrate the crash is...
Code change:
<ins> // Copyright 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. use std::ops::Add; fn f<T: Add>(a: T, b: T) -> <T as Add>::Output { a + b } fn main() { println!("a + b is {}", f::<f32>(100f32, 200f32)); } </ins>

Related discussion:
text: compile with opt-level = 2 (works fine with opt-level=0)
strange. the program looks legit to me.
this works for me now, as of
This prints on all opt levels for me at .