jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn vec_ice(_attr: TokenStream, input: TokenStream) -> TokenStream { // This redundant convert is necessary to reproduce ICE. input.into_iter().collect() } </ins>

Related discussion:
text: Follow up to and , as per Minimize a test that exercises the same codepath as
As already stated in the proc macro can be reduced to:
How do you write a UI test that depends on 3rd-party libraries?
is an example of a test that relies on a procmacro, and we can use snippet for the necessary proc_macro being tested.
Code change:
match view_path.node { ViewPathSimple(binding, ref full_path) => { <del> let source_name = full_path.segments.last().unwrap().identifier.name; if source_name.as_str() == "mod" || source_name.as_str() == "self" { </del> <ins> let mut source = full_path.segments.last().unwrap().identifier; let source_name = source.name.as_str(); if source_name == "mod" || source_name == "self" { </ins> resolve_error(self, view_path.span, ResolutionError::SelfImportsOnlyAllowedWithin); <ins> } else if source_name == "$crate" && full_path.segments.len() == 1 { let crate_root = self.resolve_crate_var(source.ctxt); let crate_name = match crate_root.kind { ModuleKind::Def(_, name) => name, ModuleKind::Block(..) => unreachable!(), }; source.name = crate_name; self.session.struct_span_warn(item.span, "`$crate` may not be imported") .note("`use $crate;` was erroneously allowed and  will become a hard error in a future release") .emit(); </ins> } <del> let subclass = ImportDirectiveSubclass::single(binding.name, source_name); </del> <ins> let subclass = ImportDirectiveSubclass::single(binding.name, source.name); </ins> let span = view_path.span; self.add_import_directive(module_path, subclass, span, item.id, vis); }

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
//! //! [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/mir/index.html <del> // ignore-tidy-filelength </del> use crate::mir::interpret::{GlobalAlloc, Scalar}; use crate::mir::visit::MirVisitable; use crate::ty::adjustment::PointerCast;

Related discussion:
text: moved the file to over 3k LOC, but I didn't fix it there and instead just annotated the file so tidy ignores it. We should probably split the mir types into separate submodules by the way they are used in MIR. I think we can start by pulling out e.g. terminators and all their sub-types to a submodule <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will be interested in picking this up
Code change:
all( not(target_arch = "aarch64"), not(target_arch = "powerpc"), <ins> not(target_arch = "s390x"), </ins> not(target_arch = "x86_64") ), all(target_arch = "aarch64", any(target_os = "macos", target_os = "ios")),

Related discussion:
text: fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.
Code change:
let hir_id = self.tcx().hir().as_local_hir_id(def_id).unwrap(); let instantiated_ty = self.resolve(&opaque_defn.concrete_ty, &hir_id); <ins> debug_assert!(!instantiated_ty.has_escaping_bound_vars()); </ins> let generics = self.tcx().generics_of(def_id); let definition_ty = if generics.parent.is_some() {

Related discussion:
text: cc
Am I correct in assuming that this should not compile, but report an error about returning a reference to the local variable ? Or is the self-borrowing generator part what makes this work? so the is part of the generator struct and the is the yielded thing? I'll try pretty printing to the expanded HIR, since I'm not sure what's going on there
Expanded version:
No, this should definitely compile. isn't yielded, but yes, it's a local variable inside the generator (that references another local variable in the generator).
Hmm, so because the generator contains references, it has lifetimes, but these lifetimes actually refer to the generator again? Do we have a special kind of lifetime that we use for this? We should just ignore those generator lifetimes for existential types.
There's no special lifetime afaik (cc
We should ignore all bound regions. Function pointers have the same issue:
Code change:
src_href: src_href.as_deref(), }; <del> let heading = item_vars.render().unwrap(); buf.write_str(&heading); </del> <ins> item_vars.render_into(buf).unwrap(); </ins> match *item.kind { clean::ModuleItem(ref m) => item_module(buf, cx, item, &m.items),

Related discussion:
text: A further performance improvement here would be to make sure that impls , in which case we could use rather than , avoiding the allocation of a temporary here. internally seems to just hold a and it has and methods already, so perhaps it would make sense to implement that trait? I'm not sure how big/relevant the performance improvement would be. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since implementers get a generated for them by Askama's macro, the simpler way to get the meat of this change would probably be to call
claim Let me take a stab at it :)
Code change:
expr: &hir::Expr<'_>, found: Ty<'tcx>, expected: Ty<'tcx>, <ins> mismatch_span: Span, </ins> ) -> bool { let map = self.tcx.hir();

Related discussion:
text: I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 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: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble
Code change:
&& adt.is_fundamental() { for ty in generics { <del> if let Some(did) = ty.def_id(self.cache) { dids.insert(did); } </del> <ins> dids.extend(ty.def_id(self.cache)); </ins> } } }

Related discussion:
text: Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.
Code change:
<ins> error: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-61963.rs:20:14 | LL |     bar: Box<Bar>, |              ^^^ help: use `dyn`: `dyn Bar` | note: lint level defined here --> $DIR/issue-61963.rs:3:9 | LL | #![deny(bare_trait_objects)] |         ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Related discussion:
text: One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.
Code change:
<ins> // Note: this test is paired with logo-class.rs. // @has logo_class_default/struct.SomeStruct.html '//*[@class="logo-container"]/img[@class="rust-logo"]' '' // @has logo_class_default/struct.SomeStruct.html '//*[@class="sub-logo-container"]/img[@class="rust-logo"]' '' pub struct SomeStruct; </ins>

Related discussion:
text: In RustCrypto crates we use which changes style depending on preferred theme using CSS rules. You can see the for an example which uses it. But the problem is how the logo gets rendered on dark themes: ! ! The reason for such horrible result is the white shadow filter applied to the logo. I understand why it was , but I think it's a wrong approach, especially for projects which aim to properly support dark themes in their media files.
There was a mention back when this was implemented about how it is not possible for a media query approach to work, when I look at the sha2 docs it looks like ! because I use a light theme generally in my browser, but have rustdoc explicitly set to a dark theme. I'm confused why the outline is being applied to these docs though, was meant to only apply it to the default rust logo, and I don't see any relevant newer PRs when searching for .
I believe I broke this in In we are supposed to apply the class only when the logo is the default one. In I missed that distinction and now the always gets the rust-logo class, even when it's a custom logo. I'll fix.
By the way, to confirm what said: the media query embedded in the SVG isn't really right. That gets the browser's preferred light/dark mode, but the user may have overridden that in rustdoc settings. As a concrete example, I'm using Chrome on Linux, which doesn't have a light/dark mode setting. I can select a dark theme in rustdoc settings, which will get me this for the Rust Crypto logo (with applied): ! That's still an improvement over the status quo, and overall I think it's fine. But if we really wanted to support theme-sensitive logos perfectly, I think we'd need to offer separate configuration options for a light logo and a dark logo.
I believe that the media query approach is a correct one in principle. But I agree that, unfortunately, the current state of browsers is far from ideal, e.g. it would be nice to have a way to switch preferred mode for a page using CSS or JS. I'm using Chrome on Linux, which doesn't have a light/dark mode setting Well, it kind of has. Try launching it with (I don't have Chrome installed, but I think it should work similarly).
Code change:
.and_modify(|e| { *e = (e.0.clone(), Some(rhs.ty().unwrap().clone())) }) <del> .or_insert((None, Some(rhs.ty().unwrap().clone()))); </del> <ins> .or_insert(( PolyTrait { trait_: trait_.clone(), generic_params: Vec::new(), }, Some(rhs.ty().unwrap().clone()), )); </ins> continue; }

Related discussion:
text: No crash in stable 1.62.1, crashes with nightly 2022-07-24 and 2022-08-03 : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label -E-needs-mcve
Was this at least on a project you can share the source to, or was it closed source? If it's a big project that you can't minimise, then it would be good to share/link to that, so someone else can do the minimisation. an example is better than no example, even if it's not minimal.
Managed to find something. The bound seems crucially important.
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-02 regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
Code change:
else_ty) } None => { <del> check_block_no_value(fcx, then_blk); ty::mk_nil() </del> <ins> infer::common_supertype(fcx.infcx(), infer::IfExpressionWithNoElse(sp), false, then_ty, ty::mk_nil()) </ins> } };

Related discussion:
text: I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:
Code change:
if !self.any_library { // If we are building an executable, only explicitly extern // types need to be exported. <del> if has_custom_linkage(self.tcx, search_item) { </del> <ins> let codegen_attrs = if self.tcx.def_kind(search_item).has_codegen_attrs() { self.tcx.codegen_fn_attrs(search_item) } else { CodegenFnAttrs::EMPTY }; let is_extern = codegen_attrs.contains_extern_indicator(); let std_internal = codegen_attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL); if is_extern || std_internal { </ins> self.reachable_symbols.insert(search_item); } } else {

Related discussion:
text: I tried this code: I expected to see this happen: Compiles successfully. Instead, this happened: Fails with this error: nightly-2024-06-26 and earlier. nightly-2024-06-27 and later, starting with . See for a discussion of the issue. : cc
To elaborate, the difference is in symbols.o. Here's a dump of symbols.o before the change: And here's after: Spot the difference. Spoiler: is now present.
So is that right or wrong? The static is "used" so marking it exported to ensure it does not get optimized away seems to make sense? I don't understand why this is a problem only on Windows.
Well that's not a problem per se but if we want to do that then we have to do it properly. is defined as a in (on my machine). This is linked directly and not in a lib file. So it's already being included. There's no reason for to include it. The only issue is that is being emitted as a comdat, meaning the linker is still allowed to remove it. We could just not do that (or add a linker directive). But that's a pre-existing issue.
I don't understand any part of that.^^ Should my PR get reverted or is there a better way to fix this regression? If there is a better way, I am afraid I lack the knowledge to implement and test it. I don't understand symbol handling on Linux, let alone on Windows.
I don't know enough about the Rust compiler to say. My complete guess would be that was silently broken before but now it's nosily broken.
Hm, who would understand our Windows linking story? ?
After CGU partitioning, we try to internalize symbols when possible. What is surprising to me is that this process only looks at export level, ignoring used attribute (in the contrast to say the internalization during fat LTO). Consequently we have a situation where synthetic object file references a symbol that is no longer exported (on Linux that does not result in a linking error, even though reference is unresolved). Anyway, if the consequence of would be to export those symbols for no reason, that seems rather counter productive to me.
Code change:
if !self.any_library { // If we are building an executable, only explicitly extern // types need to be exported. <del> if has_custom_linkage(self.tcx, search_item) { </del> <ins> let codegen_attrs = if self.tcx.def_kind(search_item).has_codegen_attrs() { self.tcx.codegen_fn_attrs(search_item) } else { CodegenFnAttrs::EMPTY }; let is_extern = codegen_attrs.contains_extern_indicator(); let std_internal = codegen_attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL); if is_extern || std_internal { </ins> self.reachable_symbols.insert(search_item); } } else {

Related discussion:
text: Ah, the behaviour was working to spec before: So I think I'd agree that is the wrong approach and should be reverted because this currently ends up conflating different things. Maybe changes elsewhere would fix this but I don't want to speculate.
the separate issue you pointed out earlier in is presumably still relevant for ?
Could this explain recent CI flakiness? The failure at and a couple other failed merges (linked on that thread, also the retries) have been msvc linker errors.
That's unfortunate. :/ Our reachable symbol code is such a spaghetti mess... I guess I'll just have to copy-paste more things into Miri then. :shrug: I am traveling right now, I'd appreciate if someone else could do the revert.
The following patch should fix the incorrect internalization I mentioned earlier: As for the question whether those symbols should be exported in the first place, it might be necessary for COFF and . The following code suggests that would not have the desired effect otherwise I don't have access to windows environment at the moment to verify that, so I don't plan to work on this myself.
Ooh this is also the stuff that also broke several ci-runs already ...
Looks like this did not fully fix the ci failures :melting_face:
Makes sense: some CI failures look non-deterministic, while we'd expect this error not to be.
Alternative approach for Miri:
Code change:
<ins> error[E0271]: type mismatch resolving `<&i32 as Deref>::Target == String` --> $DIR/default-body-type-err.rs:7:22 | LL |     fn lol(&self) -> impl Deref<Target = String> { |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, found struct `String` LL | LL |         &1i32 |         ----- return type was inferred to be `&i32` here error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Related discussion:
text: Here's a MVCE: I expected to see this happen: compilation fails because I'm clearly returning an instead of a Instead, this happened: bad codegen ("async fn resumed after completion") :
This is specifically a bug with default body in traits, this doesn't happen in s. I'll check it out, it's probably a very simple fix.
Code change:
<ins> trait Trait {} impl Trait for i32 {} // Since `Assoc` doesn't actually exist, it's "stranded", and won't show up in // the list of opaques that may be defined by the function. Make sure we don't // ICE in this case. fn produce<T>() -> impl Trait<Assoc = impl Trait> { //~^ ERROR associated type `Assoc` not found for `Trait` 16 } fn main () {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not unify with revealed type:', 'error: internal compiler error: could not unify with revealed type:' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
crashes since cc
Note: ICEs aren't crashes, we have a separate label for crashes (they mean segfaults and similar)
ungraceful exit of the compiler has been observed since :upsidedownface:
This has nothing to do with non-lifetime binders. I somewhat expect that when a "minimized" repro is tagged with a feature tag, there has been an attempt to check that the ICE is actually dependent on the feature, since that affects the prioritization of the issue.