jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(const_generics)] pub struct Struct<const N: usize>(pub [u8; N]); pub type Alias = Struct<2>; pub fn function(value: Struct<3>) -> u8 { value.0[0] } </ins>

Discussion:
Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: and got this: Not sure if it's a known issue or not but if there's anything else you need from me please let me know :)
version:
verbose trace:
It would help if you can reduce the problem to a minimal reproducer without the crate. (Also note that ICEs are common for .)
Not sure if i can manage that. Could be over my head.
there is a minimal example here:
Change:
use rustc_span::{BytePos, Span}; use crate::errors::{ <del> BreakInsideAsyncBlock, BreakInsideClosure, BreakNonLoop, ContinueLabeledBlock, OutsideLoop, </del> <ins> BreakInsideClosure, BreakInsideCoroutine, BreakNonLoop, ContinueLabeledBlock, OutsideLoop, </ins> OutsideLoopSuggestion, UnlabeledCfInWhileCondition, UnlabeledInLabeledBlock, };

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
endef <del> $(foreach host,$(CFG_HOST),$(eval $(call DEF_OSX_PKG,$(host)))) </del> <ins> ifneq ($(CFG_ENABLE_DIST_HOST_ONLY),) $(foreach host,$(CFG_HOST),$(eval $(call DEF_OSX_PKG,$(host),$(host)))) else $(foreach host,$(CFG_HOST),$(eval $(call DEF_OSX_PKG,$(host),$(TARGET)))) endif </ins> dist-osx: $(foreach host,$(CFG_HOST),dist/$(PKG_NAME)-$(host).pkg)

Discussion:
Currently, Servo uses snapshots generated from . This works great for self-targeting builds, but there's no support today for generating cross-compilation snapshots. This feature is required to support Servo Android test machines on Travis CI. I see that handles cross-compilation: It would be great if there were a different (?), too, to support this scenario.
If I went ahead and created such a target, is that something you would be open to?
Sounds reasonable to me!
I've started the patch to do this. There is some existing cruft from somebody making a similar half-fix previously that needs to be deleted. Doing it right I will involve switching the default behavior to package all targets, leaving the current behavior as a special case for our bots, which means we need to update the bots. It looks pretty easy though and I hope to have it done tomorrow.
Thanks! That explains the confusion I had - I kept getting halfway through it and then getting very confused because it looked like it should be doing what I wanted already.
Change:
tcx: &'a ty::ctxt<'tcx>, live_symbols: Box<HashSet<ast::NodeId>>, struct_has_extern_repr: bool, <del> ignore_paths: bool </del> <ins> ignore_non_const_paths: bool </ins> } impl<'a, 'tcx> MarkSymbolVisitor<'a, 'tcx> {

Discussion:
This may be related to but here is some test code for this specific case: Which prints: Ideally this would not issue a warning.
Change:
pub fn generate_fn_name_span(&self, span: Span) -> Option<Span> { let prev_span = self.span_extend_to_prev_str(span, "fn", true); <del> self.span_to_snippet(prev_span) .map(|snippet| { let len = snippet .find(|c: char| !c.is_alphanumeric() && c != '_') .expect("no label after fn"); prev_span.with_hi(BytePos(prev_span.lo().0 + len as u32)) }) .ok() </del> <ins> if let Ok(snippet) = self.span_to_snippet(prev_span) { debug!( "generate_fn_name_span: span={:?}, prev_span={:?}, snippet={:?}", span, prev_span, snippet ); if snippet.is_empty() { return None; }; let len = snippet .find(|c: char| !c.is_alphanumeric() && c != '_') .expect("no label after fn"); Some(prev_span.with_hi(BytePos(prev_span.lo().0 + len as u32))) } else { None } </ins> } /// Takes the span of a type parameter in a function signature and try to generate a span for

Discussion:
[edit: better minified version in the next comment] With, in : (If I didn't make a mistake in the process, I haven't been able to reproduce by reproducing manually what the crate does, so I'd guess it's probably related to it actually being a proc macro) : Also failed with: <details<summary<strongBacktrace</strong</summary<p</p</details
I've just found a better minified version: Note that when removing the after the , the ICE vanishes (hence my originally thinking I couldn't simplify the example more, as my auto-format would remove the comma)
Change:
<ins> fn main() { (|| {})(|| { //~^ ERROR this function takes 0 arguments but 1 argument was supplied let b = 1; }); } </ins>

Discussion:
If using format inside a closure (e.g. in iter functions) and the returning String is passed into a function that takes less args, rustc panics. Minimized code snippet: version: 1.60.0-beta.2 and 1.61.0-nightly query: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
playground link:
Probably duplicate of
Actually, not sure if it's a duplicate of . Still failing on master after the fix for that one landed, and failed with the same error (and not a duplicated adjustment bug) on beta. I will look into it! claim
Minimized:
Change:
if pos > 1 && (annotation.has_label() || annotation.takes_space()) { for p in line_offset + 1..=line_offset + pos { buffer.putc(p, <del> code_offset + annotation.start_col - margin.computed_left, </del> <ins> (code_offset + annotation.start_col).saturating_sub(left), </ins> '|', style); }

Discussion:
In we account for the visible char width when calculating the label and span positions, but we do not do so for the vertical bar tying them together, causing the following output: where it should be (Found during )
I would like to solve this as a first time issue. Best with some pointers where to start :)
the code that draws the vertical lines is at and the one that draws the span labels is right below I think the error might be using instead of , but I'm not entirely certain. If this is your first time compiling , you probably want to read the , but the TL;DR: is "run to build the compiler up to the first stage and update the test output files". You might also want to wait until the linked PR is merged so you have a test case, unless you wish to come up with a new one (look for a test that has multiple labels in the same span and pad the source to the left with unicode chars on non-1 width).
Thank you! I did read the rustc guide, and even compiled it on my own once. But thanks for the direction, and the note to the PR. I'll do my best :wink:
Change:
if place.local == ty::CAPTURE_STRUCT_LOCAL && let Some((&mir::ProjectionElem::Field(idx, _), projection)) = place.projection.split_first() <del> && let Some(&(remapped_idx, remapped_ty, needs_deref, additional_projections)) = </del> <ins> && let Some(&(remapped_idx, remapped_ty, needs_deref, bridging_projections)) = </ins> self.field_remapping.get(&idx) { // As noted before, if the parent closure captures a field by value, and // the child captures a field by ref, then for the by-move body we're // generating, we also are taking that field by value. Peel off a deref, <del> // since a layer of reffing has now become redundant. let final_deref = if needs_deref { </del> <ins> // since a layer of ref'ing has now become redundant. let final_projections = if needs_deref { </ins> let Some((mir::ProjectionElem::Deref, projection)) = projection.split_first() else { bug!(

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
Sorry you hit this ICE. This should be fixed by , which landed 15 minutes ago, though will probably not make it into nightly until two days from now (10 April 2024).
Actually, it's not yet fixed. I have a follow-up PR that will fix this :facepalm:
Change:
Ok(infcx.tcx.mk_ty_var(var)) }; let (a, b) = if self.a_is_expected { (a, b) } else { (b, a) }; <del> let (a, b) = match (a.kind(), b.kind()) { </del> <ins> let (ga, gb) = match (a.kind(), b.kind()) { </ins> (&ty::Opaque(..), _) => (a, generalize(b, true)?), (_, &ty::Opaque(..)) => (generalize(a, false)?, b), _ => unreachable!(), }; self.fields.obligations.extend( infcx <del> .handle_opaque_type(a, b, true, &self.fields.trace.cause, self.param_env())? </del> <ins> .handle_opaque_type(ga, gb, true, &self.fields.trace.cause, self.param_env()) // Don't leak any generalized type variables out of this // subtyping relation in the case of a type error. .map_err(|err| { let (ga, gb) = self.fields.infcx.resolve_vars_if_possible((ga, gb)); if let TypeError::Sorts(sorts) = err && sorts.expected == ga && sorts.found == gb { TypeError::Sorts(ExpectedFound { expected: a, found: b }) } else { err } })? </ins> .obligations, ); <del> Ok(a) </del> <ins> Ok(ga) </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. --This was in a closed source codebase I don't have time to minimize right now. It happened when I called (or something like that, don't exactly remember) on a value with type . Don't remember what T or E were :( <!-- 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
might be related to one of these ^^
Ugh, this is due to adding this  call -- something is calling this with a type that has region variables that no longer exist, probably from an or ... I can possibly try to reproduce, but this will be difficult to do without an MVCE.
can you try or is this a different issue?
This is a different issue. is a trait solver issue having to do with higher ranked type equality and the . This has to do with a region variable escaping out of a . Specifically it's this one:
Actually wait this is a type variable that's escaping. Ugh, probably due to opaque types :?
oh I forgot I saved this code I will try to trim it down to something I can post publicly
if you can, it would be incredibly useful here.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
// (item, renamed) crate items: Vec<(&'hir hir::Item<'hir>, Option<Ident>)>, crate foreigns: Vec<(&'hir hir::ForeignItem<'hir>, Option<Ident>)>, <del> crate macros: Vec<Macro>, </del> <ins> crate macros: Vec<(&'hir hir::MacroDef<'hir>, Option<Ident>)>, </ins> crate is_crate: bool, }

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
/// [`IntoIterator`]: ../book/ch13-04-performance.html /// [range patterns]: ../reference/patterns.html?highlight=range#range-patterns /// [`for`]: keyword.for.html <ins> /// /// The other use of `in` is with the keyword `pub`. It allows users to declare an item as visible /// only within a given scope. /// /// ## Literal Example: /// ///    * `pub(in crate::outer_mod) fn outer_mod_visible_fn() {}` - fn is visible in `outer_mod` /// /// Starting with the 2018 edition, paths for `pub(in path)` must start with `crate`, `self` or /// `super`. The 2015 edition may also use paths starting with `::` or modules from the crate root. /// /// For more information, see the [Reference]. /// /// [Reference]: ../reference/visibility-and-privacy.html#pubin-path-pubcrate-pubsuper-and-pubself </ins> mod in_keyword {} #[doc(keyword = "let")]

Discussion:
The only mentions 's use with loops, but that keyword has one other use that I am aware of, specifying a visibility path for an item, . This should be documented there as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} } <del> // Finally, run `decorate`. decorate(&mut err); </del> <ins> // Finally, run `decorate`. `decorate` can call `trimmed_path_str` (directly or indirectly), // so we need to make sure when we do call `decorate` that the diagnostic is eventually // emitted or we'll get a `must_produce_diag` ICE. // // When is a diagnostic *eventually* emitted? Well, that is determined by 2 factors: // 1. If the corresponding `rustc_errors::Level` is beyond warning, i.e. `ForceWarning(_)` //    or `Error`, then the diagnostic will be emitted regardless of CLI options. // 2. If the corresponding `rustc_errors::Level` is warning, then that can be affected by //    `-A warnings` or `--cap-lints=xxx` on the command line. In which case, the diagnostic //    will be emitted if `can_emit_warnings` is true. let skip = err_level == rustc_errors::Level::Warning && !sess.dcx().can_emit_warnings(); if !skip { decorate(&mut err); } </ins> explain_lint_level_source(lint, level, src, &mut err); err.emit() }

Discussion:
Input:
Bisects to Rust 1.55.0, and nightly-2021-07-20. In older stable and nightly releases, this compiles successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection points to rollup If I had to guess, I'd say that looks like the one. It's the only one in the rollup touching diagnostic code. Possibly my reasoning is off (pls correct me).
Something went wrong with your bisect, as is from 2022-02-02, whereas this ICE is present in nightly-2021-07-20. looks the most likely to me.
Either way, this is probably easier to debug from scratch instead of digging around commits. Previous issue with this ICE message should reveal information on how to fix these issues, which arise from eagerly formatting paths in lints instead of only when they're emitted.
Fix for a similar issue :
Change:
//   triggers an error // - a similar test that triggers a previously-untested const UB error: emitted close to the above //   error, it checks the correctness of the size <ins> // // As is, this code will only hard error when the constants are used, and the errors are emitted via // the `#[allow]`-able `const_err` lint. However, if the transparent wrapper technique to prevent // reborrows is used -- from `ub-wide-ptr.rs` -- these two errors reach validation and would trigger // ICEs as tracked by #86193. So we also use the transparent wrapper to verify proper validation // errors are emitted instead of ICEs. // stderr-per-bitwidth // normalize-stderr-test "allocd+" -> "allocN" </ins> trait Trait {}

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
continue }; <del> let scope = </del> <ins> let eager_expansion_root = </ins> if self.monotonic { invoc.expansion_data.id } else { orig_expansion_data.id }; <del> let ext = match self.cx.resolver.resolve_macro_invocation(&invoc, scope, force) { </del> <ins> let ext = match self.cx.resolver.resolve_macro_invocation( &invoc, eager_expansion_root, force ) { </ins> Ok(ext) => ext, Err(Indeterminate) => { undetermined_invocations.push(invoc);

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
_ => if token.can_begin_type() { IsInFollow::Yes } else { <del> IsInFollow::No(tokens) </del> <ins> IsInFollow::No(TOKENS) </ins> } }, TokenTree::MetaVarDecl(_, _, frag) if frag.name == sym::ident || frag.name == sym::ty || frag.name == sym::path => IsInFollow::Yes, <del> _ => IsInFollow::No(tokens), </del> <ins> _ => IsInFollow::No(TOKENS), </ins> } }, "" => IsInFollow::Yes, // kw::Invalid

Discussion:
E.g. in a vec is created, only to be thrown away if the macro actually works out. I think we can just turn most places into an early return in the happy path and then only allocate in the error path. Do not work on this issue before is merged. Also, hasn't had its docs updated to reflect the source changes.
Are there any reasons to not use constant/static slices and convert them to vecs on demand? Or maybe even convert to something like so there's no need to allocate vecs (In all cases) anymore?
That's a great idea! I haven't checked whether it'll work everywhere, but I think it should.
Change:
//@compile-flags: -Zmiri-disable-stacked-borrows fn main() { let v: Vec<u8> = Vec::with_capacity(10); <del> let undef = unsafe { *v.get_unchecked(5) }; //~ ERROR: uninitialized </del> <ins> let undef = unsafe { *v.as_ptr().add(5) }; //~ ERROR: uninitialized </ins> let x = undef + 1; panic!("this should never print: {}", x); }

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: Compile with on () I expected to see this happen: Both functions should compile to approximately the same thing, with no bounds check on the since the optimizer should be able to see that the slice is at least of length 2 due to the previous unchecked indexing. Instead, this happened: contains a bounds check (only does not contain a bounds check). rustc stable (1.73.0), nightly (2023-10-17), and 1.58.0 (when was stabilized) all have approximately the same codegen. : (no backtrace) label +C-optimization -C-bug
contains an assume intrinsic, doesn't. Might be worth adding it to the latter and see how that impacts perf, it's not guaranteed that it would actually improve things since we'd be emitting more IR and llvm would have to work harder. Commonly it's the case that if one uses one does so for all accesses on the slice, so this seems like an unusual pattern.
Change:
}, ); } <del> Ok((ty, kind, item.def_id)) </del> <ins> Ok((ty, DefKind::AssocTy, assoc_ty_did)) } fn lookup_assoc_ty( &self, ident: Ident, block: hir::HirId, span: Span, scope: DefId, ) -> Option<DefId> { let tcx = self.tcx(); let (ident, def_scope) = tcx.adjust_ident_and_get_scope(ident, scope, block); // We have already adjusted the item name above, so compare with `ident.normalize_to_macros_2_0()` instead // of calling `find_by_name_and_kind`. let item = tcx.associated_items(scope).in_definition_order().find(|i| { i.kind.namespace() == Namespace::TypeNS && i.ident(tcx).normalize_to_macros_2_0() == ident })?; let kind = DefKind::AssocTy; if !item.visibility(tcx).is_accessible_from(def_scope, tcx) { let kind = kind.descr(item.def_id); let msg = format!("{kind} `{ident}` is private"); let def_span = self.tcx().def_span(item.def_id); tcx.sess .struct_span_err_with_code(span, &msg, rustc_errors::error_code!(E0624)) .span_label(span, &format!("private {kind}")) .span_label(def_span, &format!("{kind} defined here")) .emit(); } tcx.check_stability(item.def_id, Some(block), span, None); Some(item.def_id) </ins> } fn qpath_to_ty(

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. <ins> - Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. </ins> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and

Discussion:
(wrapped by hand to make the problem clear) The function pointer alignment is the same as our powerpc64-unknown-linux-gnu target, so the discrepancy must be in LLVM. While this is a tier 3 target, we are completely unable to generate code for it, so at some point this part of the target tier policy will become relevant (emphasis mine): If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (there are none, not even for the Tier 2 -gnu variant) (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. I have trawled the issue tracker and I cannot find any evidence that this target is in use; all issues seem related to or the targets.
Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like is the maintainer with musl. Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like may be what broke this.
powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.
So I'm running into this in , the relevant code in LLVM is: () () We get rather than because of the musl-ness of the target. As far as I can tell, this would have been the case since , and the definition of hasn't changed . I think we just got this value wrong in .
Just as a side note – I am using it and I've hit this bug while building the current stable branch. Thank you for maintaining it.