jiebi/CodeConvo huggingface dataset:
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-arm // ignore-aarch64 </del> <ins> // Test that `extern "stdcall"` is properly translated. // only-x86 </ins> // compile-flags: -C no-prepopulate-passes

Discussion:
Compiling code like: results in: presumably because attempts to translate it into an x86-specific ABI, which the AArch64 backend rightly rejects. already ignores for non-x86 targets: I'm not completely sure what the right answer for Rust is. I think is the rough equivalent of the above clang bit and needs to take a few more cases into account for non-x86 Windows: does that sound right? If so, I'll code up a patch.
Sounds like a good place to me!
Change:
<ins> // Regresison test for issue #75361 // Tests that we don't ICE on mismatched types with inference variables trait MyTrait { type Item; } pub trait Graph { type EdgeType; fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType>>; } impl<T> Graph for T { type EdgeType = T; fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType> + '_> { //~ ERROR `impl` panic!() } } fn main() {} </ins>

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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .
Change:
} } } <ins> fn check_linkage(&self, attr: &Attribute, span: Span, target: Target) { match target { Target::Fn | Target::Method(..) | Target::Static | Target::ForeignStatic | Target::ForeignFn => {} _ => { self.dcx().emit_err(errors::Linkage { attr_span: attr.span, span }); } } } </ins> } impl<'tcx> Visitor<'tcx> for CheckAttrVisitor<'tcx> {

Discussion:
I tried this code: I expected to see this happen: compilation failure because of attribute on an item where it makes no sense Instead, this happened: compiled successfully : cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} } <ins> all_native_libs.extend_from_slice(&codegen_results.crate_info.used_libraries); </ins> if sess.opts.prints.contains(&PrintRequest::NativeStaticLibs) { print_native_static_libs(sess, &all_native_libs, &all_rust_dylibs); }

Discussion:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.
Change:
// Match the impl self type against the base ty. If this fails, // we just skip this impl, since it's not particularly useful. let impl_trait_ref = ocx.normalize(&cause, self.param_env, impl_trait_ref); <del> ocx.eq(&cause, self.param_env, impl_trait_ref.self_ty(), base_ty)?; </del> <ins> ocx.eq(&cause, self.param_env, base_ty, impl_trait_ref.self_ty())?; </ins> // Register the impl's predicates. One of these predicates // must be unsatisfied, or else we wouldn't have gotten here

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
Regression in nightly-2023-04-20 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests, r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3 ERROR: no CI builds available between and within last 167 days
Oh this might be contained in the first rollup ping reduced a bit: `
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
}, def_id.to_def_id(), ); <del> if let Some(param) = assoc_item.map(|item| &tcx.generics_of(item.def_id).params[idx]).filter(|param| param.kind.is_ty_or_const()) </del> <ins> if let Some(assoc_item) = assoc_item && let param = &tcx.generics_of(assoc_item.def_id).params[idx] && matches!(param.kind, ty::GenericParamDefKind::Const { .. }) </ins> { <del> tcx.type_of(param.def_id).subst_identity() </del> <ins> tcx.type_of(param.def_id) .no_bound_vars() .expect("const parameter types cannot be generic") </ins> } else { // FIXME(associated_const_equality): add a useful error message here. tcx.ty_error_with_message( DUMMY_SP, <del> "Could not find associated const on trait", </del> <ins> "Could not find const param on associated item", </ins> ) } }

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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
/// in an existing allocation, then returns Err containing the position /// where such allocation should be inserted fn find_offset(&self, offset: Size) -> Result<Position, Position> { <del> // We do a binary search. let mut left = 0usize; // inclusive let mut right = self.v.len(); // exclusive loop { if left == right { // No element contains the given offset. But the // position is where such element should be placed at. return Err(left); } let candidate = left.checked_add(right).unwrap() / 2; let elem = &self.v[candidate]; </del> <ins> self.v.binary_search_by(|elem| -> std::cmp::Ordering { </ins> if offset < elem.range.start { // We are too far right (offset is further left). <del> debug_assert!(candidate < right); // we are making progress right = candidate; </del> <ins> std::cmp::Ordering::Greater </ins> } else if offset >= elem.range.end() { // We are too far left (offset is further right). <del> debug_assert!(candidate >= left); // we are making progress left = candidate + 1; </del> <ins> std::cmp::Ordering::Less </ins> } else { // This is it! <del> return Ok(candidate); </del> <ins> std::cmp::Ordering::Equal </ins> } <del> } </del> <ins> }) </ins> } /// Determines whether a given access on `range` overlaps with

Discussion:
You can't create pure closures right now. This is sometimes helpful in writing functions that operate on const data. I think this will just be a matter of adjusting typeck to determine purity from the expected type.

As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .
Change:
retry make prepare <del> make check-bootstrap </del> # Display the CPU and memory information. This helps us know why the CI timing # is fluctuating. if isMacOS; then

Discussion:
It's very confusing that this can't actually be run through x.py itself; it tripped me up in See for the existing code and for where it should be moved. label +A-rustbuild +E-easy +E-mentor +E-help-wanted +A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
ty: shortty(&item), name: s.to_string(), path: path.join("::").to_string(), <del> desc: shorter(item.doc_value()), </del> <ins> desc: Escape(&shorter(item.doc_value())).to_string(), </ins> parent: parent, search_type: get_index_search_type(&item, parent_basename), });

Discussion:
By escaped, I mean stuff like which renders fine in non-search listings (it looks like , instead of a literal iframe element on the page).
I thought we had an issue for this, but cannot find it.
Relevant to inline summary rendering:
Search result descriptions aren't markdown rendered and read/written unaltered from the search-index to the page. Should these descriptions be markdown rendered or html escaped ()?
Change:
} // Actual LTO type we end up choosing based on multiple factors. <del> enum ComputedLtoType { </del> <ins> pub enum ComputedLtoType { </ins> No, Thin, Fat, } <del> fn execute_optimize_work_item<B: ExtraBackendMethods>( cgcx: &CodegenContext<B>, module: ModuleCodegen<B::Module>, module_config: &ModuleConfig, ) -> Result<WorkItemResult<B>, FatalError> { let diag_handler = cgcx.create_diag_handler(); unsafe { B::optimize(cgcx, &diag_handler, &module, module_config)?; </del> <ins> pub fn compute_per_cgu_lto_type( sess_lto: &Lto, opts: &config::Options, sess_crate_types: &[CrateType], module_kind: ModuleKind, ) -> ComputedLtoType { // Metadata modules never participate in LTO regardless of the lto // settings. if module_kind == ModuleKind::Metadata { return ComputedLtoType::No; </ins> } <del> // After we've done the initial round of optimizations we need to // decide whether to synchronously codegen this module or ship it // back to the coordinator thread for further LTO processing (which // has to wait for all the initial modules to be optimized). </del> // If the linker does LTO, we don't have to do it. Note that we // keep doing full LTO, if it is requested, as not to break the // assumption that the output will be a single module. <del> let linker_does_lto = cgcx.opts.cg.linker_plugin_lto.enabled(); </del> <ins> let linker_does_lto = opts.cg.linker_plugin_lto.enabled(); </ins> // When we're automatically doing ThinLTO for multi-codegen-unit // builds we don't actually want to LTO the allocator modules if // it shows up. This is due to various linker shenanigans that // we'll encounter later. <del> let is_allocator = module.kind == ModuleKind::Allocator; </del> <ins> let is_allocator = module_kind == ModuleKind::Allocator; </ins> // We ignore a request for full crate grath LTO if the cate type // is only an rlib, as there is no full crate graph to process,

Discussion:
First compile is ok, after I modify some contents. It failed. I've to . Then works.
I don't know how to setup a minimal env to reproduce this. But I'd love to provide any info you needed.
cc Is this maybe related to ? (Although this sounds like the opposite of that, where it is missing the bit code.)
Some digging shows that this is a preexisting bug in rustc: I believe that this is only showing up now because Cargo is only just now passing
I've posted a fix for this at
Change:
<ins> <div class="docblock"><p>Par 1</p> <p>Par 2</p> </div> </ins>  No newline at end of file

Discussion:
See the test in . This code: renders as: rather than the expected: Meanwhile, changing some s to s and vice versa causes it to render as expected. cc
This is the expected behaviour actually: it converts the into a directly. So if you don't put empty doc comments between, it's as expected.
But why are the newlines in the stripped?
Oh, I didn't see that. I think it's because we use to remove whistespaces which also removes backlines. We should instead merge all doc comments before doing anything.
Change:
} <ins> /// doc /// /// ``` /// println!("hello"); /// ``` #[derive(Clone)] pub struct NiceStruct; </ins> #[doc(hidden)] pub mod foo { pub fn bar() {}

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: /// let f = Foo; /// I expected to see this happen: succeeds. Instead, this happened: <!-- 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. --:
searched nightlies: from nightly-2020-09-30 to nightly-2020-11-30 regressed nightly: nightly-2020-11-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsso probably
What is the correct option here ? Ignoring derived traits or putting default examples on the derive for those types ? The first seems hard to do but I'm maybe missing knowledge to see it done. The second means the examples won't be very relevant to the type on which they are derived. For this is not much of a problem, but for thing like I can see it confusing people.
I think rustdoc shouldn't require examples for derived traits. A possible fix is to only call in render, and use the macro span everywhere else for the purpose of lints.
Change:
param_env: ParamEnv<'tcx>, /// Caller codegen attributes. codegen_fn_attrs: &'tcx CodegenFnAttrs, <del> /// Stack of inlined Instances. history: Vec<ty::Instance<'tcx>>, </del> <ins> /// Stack of inlined instances. /// We only check the `DefId` and not the substs because we want to /// avoid inlining cases of polymorphic recursion. /// The number of `DefId`s is finite, so checking history is enough /// to ensure that we do not loop endlessly while inlining. history: Vec<DefId>, </ins> /// Indicates that the caller body has been modified. changed: bool, }

Discussion:
I tried this code with (, ; minimized and modified from 's ): I expected to see this happen: Successful compilation Instead, this happened: Compiler hangup <!-- 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. --: <details<summaryBacktrace</summary<pCaptured by a command in GDB:  </p</details
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
1|       |#![allow(unused_assignments, dead_code)] 2|       | <del> 3|       |// compile-flags: --edition=2018 -C opt-level=1 # fix in rustc_mir/monomorphize/partitioning/mod.rs </del> <ins> 3|       |// compile-flags: --edition=2018 -C opt-level=1 </ins> 4|       | 5|      1|async fn c(x: u8) -> u8 { 6|      1|    if x == 8 {

Discussion:
I tried to generate test code coverage with this source file using and the LLVM tools. Source File: I expected to see this happen: Instead, this happened: . cargo-kcov, -Zprofile+grcov, and tarpaulin agree on 76%. In the output below lines , , were not executable but should have been executable+uncovered. Line should be executable+covered. <details<summarycoverage output</summary<p</p</details:
label: +A-code-coverage cc
Thanks for the bug report ! There was a recent bug fix (PR ) that addresses most of the missing coverage in your example (except for the last one). I just tested with and I see the expected coverage now for the first three ranges you reported seeing no coverage. These three are now showing coverage (with 0 executions) as expected: I was surprised to see no coverage for line 169, and I do see the did print, so that does seem to be a bug. So as of today, this issue is still a bug that I will need to look into further:
cc: Note, here is a snippet showing the missing coverage and code relevant to its codepath. I haven't thoroughly investigated this. I should be able to reproduce this in a simplified test (without the asynctrait and executor dependencies) that I can add to our unit tests. I don't have a theory yet. It could either be the closure's MIR is not included in coverage (seems unlikely to me), or is silently dropping coverage because it doesn't like something. (This is what was happening for the other missing coverage reported in this issue, that has since been resolved.) The test (shown at the bottom) calls and awaits the implementation of below: I do see the test output, including the from above, and from the awaited call to , below: The async closure seems to be missing coverage, as shown here. Note the wrapper function is covered and called (showing the coverage of on line 168), but there should also be coverage for the awaited implicit closure (lines 168-170, I believe). Since the program output proves this is called, the coverage should be showing execution. And the test that invokes it is covered:
Thank you. I see improvement in the latest nightly.

I minified the test case to the async issues for anyone looking at this (but it still uses executor and asynctrait.) Since this function is missing coverage too the issue isn't specific to async_trait thought.
So it turns out that the internal (auto-generated) closure actually does get coverage, but for some reason the code region for the macro, by itself, is not or not counted. I've created a draft PR with a new test and current results, demonstrating this issue. Once I figure out how to fix it, I'll submit the PR with the updated results.
Update: fixes the issue.
Change:
<ins> // Copyright 2013 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. trait Serializable<'self, T> { //~ ERROR: no longer a special lifetime fn serialize(val : &'self T) -> ~[u8]; fn deserialize(repr : &[u8]) -> &'self T; } impl<'self> Serializable<str> for &'self str { fn serialize(val : &'self str) -> ~[u8] { ~[1] } fn deserialize(repr: &[u8]) -> &'self str { "hi" } } fn main() { println("hello"); let x = ~"foo"; let y = x; println(y); } </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // Copyright 2013 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. trait Serializable<'self, T> { //~ ERROR: no longer a special lifetime fn serialize(val : &'self T) -> ~[u8]; fn deserialize(repr : &[u8]) -> &'self T; } impl<'self> Serializable<str> for &'self str { fn serialize(val : &'self str) -> ~[u8] { ~[1] } fn deserialize(repr: &[u8]) -> &'self str { "hi" } } fn main() { println("hello"); let x = ~"foo"; let y = x; println(y); } </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
/// A primitive signed or unsigned integer equipped with various bitwise /// operators, bit counting methods, and endian conversion functions. pub trait Int: Primitive <ins> + Ord </ins> + CheckedAdd + CheckedSub + CheckedMul

Discussion:
Right now the Int and Integer traits imply PartialOrd but not Ord. Is there a reason for this? It seems like integers do have a total order, not just partial. I asked on IRC and people seemed to think Int should imply Ord. If this is correct I can send a pull request?
Yup :)
I have two questions: May I ask what is the trait? Couldn't find any in the std doc: Did you mean  () when you wrote "the trait"? But it doesn't even inherit . Am I missing something?
The trait is in .
Ah, it was the big int code separated from the std lib! Thanks. I also overlooked implemented , implying . Sorry for the noise!