jiebi/CodeConvo huggingface dataset:
Change:
// // This can be conveniently accessed by methods on `tcx.hir()`. // Avoid calling this query directly. <del> query hir_owner(key: LocalDefId) -> &'tcx crate::hir::Owner<'tcx> { </del> <ins> query hir_owner(key: LocalDefId) -> Option<&'tcx crate::hir::Owner<'tcx>> { </ins> eval_always desc { |tcx| "HIR owner of `{}`", tcx.def_path_str(key.to_def_id()) } }

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
<ins> // run-pass // This test verifies that the `ConstProp` pass doesn't cause an ICE when evaluating polymorphic // promoted MIR. pub trait ArrowPrimitiveType { type Native; } pub fn new<T: ArrowPrimitiveType>() { assert_eq!(0, std::mem::size_of::<T::Native>()); } impl ArrowPrimitiveType for () { type Native = (); } fn main() { new::<()>(); } </ins>

Discussion:
See https://travis- for failed build
Could you please provide a backtrace for the ICE?
cc
cc more const prop fallout?
Seems likely. I'll have some time tonight to look at it.
Minimal repro:
Cc me
Change:
use std::mem; use std::num::NonZeroUsize; use std::ops::{ControlFlow, Deref}; <ins> use std::ptr::NonNull; </ins> /// An entity in the Rust type system, which can be one of /// several kinds (types, lifetimes, and consts).

Discussion:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)
Change:
// since they will not be detected after macro expansion. fn check_attributes(&mut self, attrs: &[ast::Attribute]) { let features = self.cx.ecfg.features.unwrap(); <del> for attr in attrs.iter() { </del> <ins> let mut attrs = attrs.iter().peekable(); let mut span: Option<Span> = None; while let Some(attr) = attrs.next() { </ins> rustc_ast_passes::feature_gate::check_attribute(attr, self.cx.sess, features); validate_attr::check_meta(&self.cx.sess.parse_sess, attr); <ins> let current_span = if let Some(sp) = span { sp.to(attr.span) } else { attr.span }; span = Some(current_span); if attrs.peek().map_or(false, |next_attr| next_attr.doc_str().is_some()) { continue; } </ins> if attr.doc_str().is_some() { self.cx.sess.parse_sess.buffer_lint_with_diagnostic( &UNUSED_DOC_COMMENTS, <del> attr.span, </del> <ins> current_span, </ins> ast::CRATE_NODE_ID, "unused doc comment", BuiltinLintDiagnostics::UnusedDocComment(attr.span),

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.
Change:
arg.into_string().unwrap_or_else(|arg| { early_error( ErrorOutputType::default(), <del> &format!("Argument {} is not valid Unicode: {:?}", i, arg), </del> <ins> &format!("argument {} is not valid Unicode: {:?}", i, arg), </ins> ) }) })

Discussion:
When debugging a large Miri trace, I like to put the trace into a file that I can analyze and search through in an editor. Unfortunately, since the recent logging changes, that leads to a lot of garbage in the file: Looks like the color escape sequences are printed even when redirecting to a file. This makes working with the logfile much harder than it was before. Is there a way to fix that? Cc
This is the fault of I should be checking for whether the terminal supports colors before activating colors
A workaround until then is to use
How can I run miri from the rust repo? (i.e. built using )
You can run the test suite with , but that's not what you were asking... that's not supported yet unfortunately:
Until then, . Some of the commands might need adjusting though as changed.
Ah, thanks! I forgot about that part of the docs :)
Hmm, I'm getting this error: I'm using the latest master rustc and the latest miri. Is miri broken right now? EDIT: Oh, I think I need .
Yeah looks like you are using the wrong stage or so. The docs are from back when stage 2 was the default...
I'm afraid the problem was not solved by that PR. When I run Miri like this locally I still get all the ANSI codes in that logfile, which makes the file very hard to work with.
Looks like the code tests , but logging goes to stderr so this is the wrong test.
Hmm, I guess I didn't notice any issues because I always redirect stderr to stdout and then view that.
Working on a fix.
Yeah, for now using to redirect both to the logfile is an okay work-around.
FYI you can view the original color with , which prints them directly to the terminal. That doesn't work in an editor, though.
Change:
"target-features" => PrintRequest::TargetFeatures, "relocation-models" => PrintRequest::RelocationModels, "code-models" => PrintRequest::CodeModels, <del> "target-spec-json" if nightly_options::is_unstable_enabled(matches) => PrintRequest::TargetSpec, </del> <ins> "target-spec-json" => { if nightly_options::is_unstable_enabled(matches) { PrintRequest::TargetSpec } else { early_error(error_format, &format!("the `-Z unstable-options` flag must also be passed to  enable the target-spec-json print option")); } }, </ins> req => { early_error(error_format, &format!("unknown print request `{}`", req)) }

Discussion:
introduced but it's a little hard to find out how to use it: Current: Expected:
Change:
Ok((fields, etc)) } <ins> /// If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest /// the correct code. fn recover_misplaced_pattern_modifiers( &self, fields: &ThinVec<PatField>, err: &mut DiagnosticBuilder<'a, ErrorGuaranteed>, ) { if let Some(last) = fields.iter().last() && last.is_shorthand && let PatKind::Ident(binding, ident, None) = last.pat.kind && binding != BindingAnnotation::NONE && self.token == token::Colon // We found `ref mut? ident:`, try to parse a `name,` or `name }`. && let Some(name_span) = self.look_ahead(1, |t| t.is_ident().then(|| t.span)) && self.look_ahead(2, |t| { t == &token::Comma || t == &token::CloseDelim(Delimiter::Brace) }) { let span = last.pat.span.with_hi(ident.span.lo()); // We have `S { ref field: name }` instead of `S { field: ref name }` err.multipart_suggestion( "the pattern modifiers belong after the `:`", vec![ (span, String::new()), (name_span.shrink_to_lo(), binding.prefix_str().to_string()), ], Applicability::MachineApplicable, ); } } </ins> /// Recover on `...` or `_` as if it were `..` to avoid further errors. /// See issue #46718. fn recover_bad_dot_dot(&self) {

Discussion:
When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:
Change:
<ins> error: lifetime may not live long enough --> $DIR/different_args_considered_equal3.rs:18:5 | LL | fn get_iter<'a>() -> impl IntoIterator<Item = Opaque<'a>> { |             -- lifetime `'a` defined here LL |     None::<Opaque<'static>> |     ^^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'a` must outlive `'static` error: aborting due to 1 previous error </ins>

Discussion:
The following should not compile. Adapted from . This is a quick issue, I did not have the chance to look into it deeper but I guess it affects ATPIT as well. cc
This used to be an error in , but then incorrectly accepted in .
Change:
fn in_value(cx: &ConstCx<'_, 'tcx>, source: ValueSource<'_, 'tcx>) -> bool { match source { ValueSource::Rvalue(rvalue) => Self::in_rvalue(cx, rvalue), <ins> ValueSource::DropAndReplace(source) => Self::in_operand(cx, source), </ins> ValueSource::Call { callee, args, return_ty } => { Self::in_call(cx, callee, args, return_ty) }

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
// FIXME(eddyb) ignoring `obligations` might cause false positives. drop(obligations); <del> let may_apply = infcx.predicate_may_hold(&traits::Obligation::new( cause.clone(), param_env, trait_ref.to_predicate(), )); </del> <ins> debug!( "invoking predicate_may_hold: {:?}", trait_ref, ); let may_apply = match infcx.evaluate_obligation( &traits::Obligation::new( cause.clone(), param_env, trait_ref.to_predicate(), ), ) { Ok(eval_result) => eval_result.may_apply(), Err(traits::OverflowError) => true, // overflow doesn't mean yes *or* no }; </ins> if !may_apply { return }

Discussion:
Steps to reproduce:
I assume this is the same as
Running into this as well when running on 1.30.0-nightly ( 2018-08-05)
Hit this on the newest nightly ( 2018-08-18)
Same issue, slightly different line number Filtered log:
any idea what's going on here? let us know if you need T-compiler help :)
I didn't check yet, still on my todo list. I'll give it a look this week-end.
It would be great to have a minimized example here =)
True, I'll try to make one.
I think this is the same as as well
visited for triage. PR just needs to be landed.
Reopening; since we never backported , rustdoc ICE's on typenum again.
visiting for triage. It looks like PR is on target to be backported to stable. (In fact, the recent update of the labels to say just leads me to assume that the backport has occurred... yes, it was part of PR )
So, only two questions I have now: I openly mused to myself during this triage session that the failure to backport to beta sooner may represent a process failure of some sort. But there may be a very simple fix: Can/should we revise bors to not autoclose issues that are tagged as stable-to-beta or stable-to-stable regressions? Filed as barosl/homu On the subject of closing: Can we close this issue in light of ? Or do we need to wait until the 1.30.1 point release has officially been deployed?
Closed since 1.30.1 was released already.
Change:
) -> PResult<'a, P<Pat>> { // Parse the first pattern (`p_0`). let first_pat = self.parse_pat(expected)?; <del> self.maybe_recover_unexpected_comma(first_pat.span, rc)?; </del> <ins> self.maybe_recover_unexpected_comma(first_pat.span, rc, gate_or)?; </ins> // If the next token is not a `|`, // this is not an or-pattern and we should exit here.

Discussion:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma
Change:
fn lower_arm(&mut self, arm: &Arm) -> hir::Arm<'hir> { let pat = self.lower_pat(&arm.pat); <del> let mut guard = arm.guard.as_ref().map(|cond| { </del> <ins> let guard = arm.guard.as_ref().map(|cond| { </ins> if let ExprKind::Let(pat, scrutinee, span, is_recovered) = &cond.kind { hir::Guard::IfLet(self.arena.alloc(hir::Let { hir_id: self.next_id(),

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)', 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)' File: --snippet: 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: [shallowlintlevelson] looking up lint levels for [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in cc
Change:
} } <ins> ast::ItemKind::GlobalAsm(..) => { self.report_unsafe(cx, it.span, BuiltinUnsafe::GlobalAsm); } </ins> _ => {} } }

Discussion:
Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.
Change:
if !is_prelude && max_vis.get() != ty::Visibility::Invisible && // Allow empty globs. !max_vis.get().is_at_least(directive.vis.get(), &*self) { <del> let msg = "A non-empty glob must import something with the glob's visibility"; self.r.session.span_err(directive.span, msg); </del> <ins> let msg = "glob import doesn't reexport anything because no candidate is public enough"; self.r.session.buffer_lint(UNUSED_IMPORTS, directive.id, directive.span, msg); </ins> } return None; }

Discussion:
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the in B) may break code that imports from that module. This causes surprises when refactoring. Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint? The original discussion is here:
The error was introduced in as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly. The error was introduced by analogy with errors for single imports (and just to be conservative): The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
Would this be a "good first issue" or is it complex to fix?
No, not complex. Find where "non-empty glob must import something" is reported. Replace with .
I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the to
Change:
<ins> // If a derive macro introduces a helper attribute with the same name as that macro, // then make sure that it's usable without ambiguities. // check-pass // aux-build:derive-helper-shadowing-2.rs #[macro_use] extern crate derive_helper_shadowing_2; #[derive(same_name)] struct S { #[same_name] // OK, no ambiguity, derive helpers have highest priority field: u8, } fn main() {} </ins>

Discussion:
So pointed out to me that some recent changes in name resolution seem to have broken . They pointed me at dealing with the fallout -- maybe you can leave a few notes as to what errors you were seeing before this commit? cc -- could this be the recent changes around name resolution of helper attributes in macros? It seems the relevant code is stuff like:
(Nominated for discussion around the breakage policy/implications here.)
Duplicate of , I'll prepare a fix.
fix Or rather a "tiebreaker" for the ambiguity, since both names are indeed in scope and create ambiguity, which is correctly detected after .
Fixed in

This is a dependency of . I was trying to compile ; it failed on both the master branch and the current published version. is ambiguous (derive helper attribute vs any other name) Indeed, the code does seem to treat as simultaneously a derive macro and an attribute macro. It works fine on stable.
Example of failing builds:
modify labels: +E-needs-bisection It'd be nice if somebody pinpointed specific PR (or nightly at least). Maybe has a clue what could have caused it.
Seems to be introduced at nightly-2019-11-17. Unfortunately I'm not able to bisect that further because cargo-bisect-rustc is telling me:
Likely
This is a consequence of , I'll provide a ASAP.
Fixed in
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-67945-2.rs:4:11 | LL | enum Bug<S> { |          - this type parameter LL |     Var = 0: S, |           ^ expected type parameter `S`, found integer | = note: expected type parameter `S` found type `{integer}` error[E0308]: mismatched types --> $DIR/issue-67945-2.rs:4:11 | LL | enum Bug<S> { |          - this type parameter LL |     Var = 0: S, |           ^^^^ expected `isize`, found type parameter `S` | = note:        expected type `isize` found type parameter `S` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.