jiebi/CodeConvo huggingface dataset:
Change:
//@ignore-target-windows: No libc on Windows #![feature(cstr_from_bytes_until_nul)] <del> use std::ffi::CStr; </del> <ins> use std::ffi::{CStr, CString}; </ins> use std::thread; fn main() {

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
<ins> // aux-build:const_generic_lib.rs extern crate const_generic_lib; fn main() { let _ = const_generic_lib::function(const_generic_lib::Struct([0u8, 1u8])); //~^ ERROR mismatched types let _: const_generic_lib::Alias = const_generic_lib::Struct([0u8, 1u8, 2u8]); //~^ ERROR mismatched types } </ins>

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.
Change:
<ins> // aux-build:const_generic_lib.rs extern crate const_generic_lib; fn main() { let _ = const_generic_lib::function(const_generic_lib::Struct([0u8, 1u8])); //~^ ERROR mismatched types let _: const_generic_lib::Alias = const_generic_lib::Struct([0u8, 1u8, 2u8]); //~^ ERROR mismatched types } </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:
// revisions: correct incorrect // check-pass <del> // [correct]compile-flags:--test --test-run-directory={{src-base}} -Zunstable-options // [incorrect]compile-flags:--test --test-run-directory={{src-base}}/coverage -Zunstable-options </del> <ins> // [correct]compile-flags:--test --test-run-directory={{src-base}} // [incorrect]compile-flags:--test --test-run-directory={{src-base}}/coverage </ins> // normalize-stdout-test: "tests/rustdoc-ui" -> "$$DIR" // normalize-stdout-test "finished in d+.d+s" -> "finished in $$TIME"

Discussion:
This is a tracking issue for the flag in rustdoc. This flag changes the directory where doctests are run. This was to support changing the directory used while running in a Cargo workspace. See for more information. None at this time. — Initial PR. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not* meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. cc
I opened with the aim to stabilize this rustdoc flag, primarily to facilitate the cargo flag, and to eventually making it the default. The flag in combination with allows specifying an explicit directory in which rustdoc will run the compiled doctests. The default, without this explicit flag, is to run the resulting doctest binaries in the same current working directory as rustdoc itself. This flag is primarily the building block for the cargo flag (See ). With that flag, doctests are handled consistently to unit- and integration tests: They will be compiled relative to the cargo workspace root, but they are run in the crate directory. The flag is currently not documented as part of the . -- highlights usage with cwd-sensitive functions inside doctests. -- shows indirect usage via the cargo flag.Similar flags that allow hooking into or observing the side effects of rustdoc test compilation, such as are not stable yet, and there does not seem to be a push to stabilization either. The usefulness of this flag when invoking manually might be limited. But it is a requirement for the cargo flag. Is there maybe a better alternative to solve the compile/run directory inconsistency that exists in cargo workspaces today?
over in expressed agreement to make the cargo flag the default, considering it rather a bugfix for the current inconsistent behavior. However, stabilizing is a requirement for that, and there does not seem to be a better alternative to it. is there anything I can do to move stabilization () forward?
Next step is the FCP. I'll start on the PR.
cargo test runs doc tests by default and doesn't allow to specify . My project uses sqlx which tries to create directory. But if fails because I run the build inside a container against immutable source. Instead I expect that the test should stay in the workspace directory and use which is mounted as a build cache volume.
Change:
ident_name: Symbol, } <ins> // FIXME: This really should be taking scoping, etc into account. </ins> impl<'v> Visitor<'v> for LetVisitor<'v> { fn visit_stmt(&mut self, ex: &'v hir::Stmt<'v>) { <del> if let hir::StmtKind::Local(hir::Local { pat, init, .. }) = &ex.kind { if let Binding(_, _, ident, ..) = pat.kind && ident.name == self.ident_name { self.result = *init; } </del> <ins> if let hir::StmtKind::Local(hir::Local { pat, init, .. }) = &ex.kind && let Binding(_, _, ident, ..) = pat.kind && ident.name == self.ident_name { self.result = *init; } else { hir::intravisit::walk_stmt(self, ex); </ins> } <del> hir::intravisit::walk_stmt(self, ex); </del> } }

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 is new, introduced between (older) and (newer) src/tools/miri/tests/pass- <!-- 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
prioritize
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 112828 struct Outer(Inner); struct Inner; unsafe impl<Q: Trait> Send for Inner {} //~^ ERROR the type parameter `Q` is not constrained by the impl trait, self type, or predicates trait Trait {} </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 is the least I've managed to reduce the code: <!-- 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. --: With nightly version the compiler asks me to change the as follows: and now the error no longer occurs. After running the command, I get the following: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOutput seems the same </p</details
Related if not duplicate of one of: , , . label -needs-triage T-rustdoc A-auto-traits A-synthetic-impls
I can't seem to reproduce the ICE with and
Me neither, seems to have been fixed. Potentially by err's “ PR” or by one of the PRs that made rustdoc execute more of rustc's stages. Fixed: ICE → errors (unsatisfied bounds).

<!-- 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
label A-synthetic-impls A-auto-traits T-compiler The bug originates in which lives in , so having both team labels is valid.
Bisection seems to point to nightly-2022-10-24, one of these:
Out of those, looks the most likely (from ).
I can no longer reproduce this. Fixed: ICE → errors. Probably fixed by one of those PRs that made rustdoc run more of rustc's passes.

Minimal example What I expected: works. What happens: (check & build work) No response No response
Thanks for the report! I have transferred this to rust-lang/rust as that is where rustdoc issues are tracked.
Seems to be a compiler bug. Adding the relevant tag.
Although the MCVE looks a bit esoteric, it actually comes from using  in an fairly straightforward way. I wouldn't be surprised if others have/will run into this.
Ran on this and found it regressed in The PR () states it's a revert of a previous commit. So maybe it was broken before the commit that needed reverting.
label A-auto-traits A-synthetic-impls
I can no longer reproduce this issue.
Change:
<ins> error: invalid label name `'static` --> $DIR/issue-52437.rs:2:13 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |             ^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52437.rs:2:30 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |                              ^ consider giving this closure parameter a type error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </ins>

Discussion:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

I'm experimenting with a parser combinator and ran into an issue with closure lifetime inference. This might be a duplicate of , since it uses a similar (but simpler) mechanism to produce the same error message. However, in the code below the error is potentially a lot further away, and since I need to return values from the closure I'm having trouble finding any way to make it work by explicitly specifying a signature. Since it involves more moving parts, I'm also not sure how to confirm if the underlying issue is the same. I removed all parts that aren't involved in triggering the error message (the original use case has trait methods with related return types). It comes down to the following error message: And here is the triggering code:
After some experimentation, I tried a possible fix, which lead to an ICE. I changed to which gives me: My is: And here is the :
The ICE reduced:
Triage: still ICEs
Still ICEs:
The reduced example doesn't show the ICE, from 1.35.0 (tested on godbolt). Marked as E-needstest
And the original code is now accepted, so adding tests is enough to close this ticket.
Change:
} } <del> /// Deprecated: use `into_iter`. #[unstable(feature = "rustc_private", issue = "0")] #[rustc_deprecated(since = "1.0.0", reason = "use into_iter")] pub fn move_iter(self) -> IntoIter<T> { self.into_iter() } </del> pub fn len(&self) -> usize { match self.repr { Zero => 0,

Discussion:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .
Change:
= note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) warning: trailing semicolon in macro used in expression position <del> --> $DIR/semicolon-in-expressions-from-macros.rs:7:13 </del> <ins> --> $DIR/semicolon-in-expressions-from-macros.rs:8:13 </ins> | LL |         true; |             ^

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 don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Change:
self.visit_nested_impl_item(id); } <ins> fn visit_foreign_item_ref(&mut self, fi: &'hir ForeignItemRef<'hir>) { // Do not visit the duplicate information in ForeignItemRef. We want to // map the actual nodes, not the duplicate ones in the *Ref. let ForeignItemRef { id, ident: _, span: _, vis: _ } = *fi; self.visit_nested_foreign_item(id); } </ins> } struct HirItemLike<T> {

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
I'm seeing this one as well. Host is a standard Github Actions container. Not sure if the below information is helpful but its additional to the above posted by HYG-YT.
I have to temporarily degrade the version of my nightly installation to 11-24 to make sure everything is functional (it's a discord bot made with twilight-rs)
Similarly, I'm attempting to knock my version back a couple of days as well-- yet to succeed but that's mostly me wrestling with my actions configuration.
I have the same on my Raspberry Pi 3 (Debian 10, Linux 4.19.66):
I can reproduce with on . searched toolchains through regression in Regressed in , cc
MCVE:
Assigning .
I updated to the latest nightly (2020-11-29) and it still fails.
Wait for next nightly. The current one doesn't contain the fix PR.
Got it!
you can also try the latest master using
Change:
// We only care about method calls corresponding to the `Clone`, `Deref` and `Borrow` // traits and ignore any other method call. <del> let did = match cx.typeck_results().type_dependent_def(expr.hir_id) { // Verify we are dealing with a method/associated function. Some((DefKind::AssocFn, did)) => match cx.tcx.trait_of_item(did) { // Check that we're dealing with a trait method for one of the traits we care about. Some(trait_id) if matches!( cx.tcx.get_diagnostic_name(trait_id), Some(sym::Borrow | sym::Clone | sym::Deref) ) => { did } _ => return, }, _ => return, </del> <ins> let Some((DefKind::AssocFn, did)) = cx.typeck_results().type_dependent_def(expr.hir_id) else { return; }; let Some(trait_id) = cx.tcx.trait_of_item(did) else { return }; if !matches!( cx.tcx.get_diagnostic_name(trait_id), Some(sym::Borrow | sym::Clone | sym::Deref) ) { return; </ins> }; let substs = cx .tcx .normalize_erasing_regions(cx.param_env, cx.typeck_results().node_substs(expr.hir_id));

Discussion:
If I have a type , and a trait that is implemented for both and , is a valid way to get a reference from an object of type . But since beta 1.71, this emits a warning. I have no idea what the warning is trying to convey, what "double reference" is referring to, or what "the inner type" is. No response
cc
Ah. then I think this lint shouldn't apply to since can mean specifically to borrow . But I think this should still apply to and
(sorry)
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
sym::vtable_align => ty::COMMON_VTABLE_ENTRIES_ALIGN, _ => bug!(), }; <del> let value = meth::VirtualIndex::from_index(idx).get_usize(bx, vtable); </del> <ins> let value = meth::VirtualIndex::from_index(idx).get_usize(bx, vtable, callee_ty); </ins> match name { // Size is always <= isize::MAX. sym::vtable_size => {

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
/// When collecting definitions from an AST fragment produced by a macro invocation `ExpnId` /// we know what parent node that fragment should be attached to thanks to this table. invocation_parents: FxHashMap<ExpnId, DefIndex>, <ins> /// Indices of unnamed struct or variant fields with unresolved attributes. pub(super) placeholder_field_indices: NodeMap<usize>, </ins> } /// A unique identifier that we can use to lookup a definition

Discussion:
Stable, and nightly-2019-09-09: nightly-2019-09-10: Mentioning because this is likely from .
Yeah, this is some known shortcut taken in , sorry. Didn't expect people to hit it that fast. Will fix ~this weekend.
Thanks. The realistic usage where this appears is if you forget to import a derive macro, which happens commonly.
Un-nominating since Vadim self-assigned.
triage: P-high.
Fixed in
Change:
), } if let Some((_, target)) = destination { <del> self.check_bb(location, *target); </del> <ins> self.check_edge(location, *target, EdgeKind::Normal); </ins> } if let Some(cleanup) = cleanup { <del> self.check_bb(location, *cleanup); </del> <ins> self.check_edge(location, *cleanup, EdgeKind::Unwind); </ins> } } TerminatorKind::Assert { cond, target, cleanup, .. } => {

Discussion:
Blocks that are part of unwinding code always need to marked as . This seems like an easy thing to check in the validation pass. I believe this would have caught a bug in the generator transform (a pretty long time ago). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Good point! Moreover, cleanup block terminators should also only jump to cleanup blocks, and other terminators should only jump to non-cleanup blocks. Basically, unwind edges must be the only ones that cross the "cleanup to non-cleanup" boundary. (Miri is already checking this.)
claim
Change:
s.push_normal(ty.to_string()); } <ins> // process starts here </ins> match (&t1.kind, &t2.kind) { (&ty::Adt(def1, sub1), &ty::Adt(def2, sub2)) => { let sub_no_defaults_1 = self.strip_generic_default_params(def1.did, sub1);

Discussion:
On E0308 type mismatch errors we already perform a basic check to type arguments in order to only highlight differences between the expected and found type. I recently came across a case where the two types had identifiers of the same length with no type arguments, but that were not local so the path was quite long. It took me some time to realize that the two types were actually different and not caused by different crate versions. It'd be nice if for the following, only the parts of the path that differ were highlighted/bolded in the CLI output: CC
Hello, I'd like to implement this feature.
Hi Will you be needing a hand? To begin with, I would recommend searching for in order to find how it works today. Particularly, shows how the highlighting for specific type arguments is currently handled. It is extremely verbose, but the comments should help somewhat. Also, the is a good primer on how to develop in the compiler's codebase. If you need a hand, don't hesitate to reach out.
Thanks, I'd found that struct and file, but I'd overlooked that method due to how complicated it seemed at a glance.
Should I add a test for this? If so, how would I implement that? The standard UI testing method doesn't seem to track highlights.
sadly, we do not have any way to test correct application of colors in the test suite. Attach screenshots to the PR so that we can see the changes, but we have to rely on being extra careful when touching this part of the codebase.