jiebi/CodeConvo huggingface dataset:
Change:
loan_issued_at: Location, ) { let sccs = self.regioncx.constraint_sccs(); <ins> let universal_regions = self.regioncx.universal_regions(); </ins> let issuing_region_scc = sccs.scc(issuing_region); // We first handle the cases where the loan doesn't go out of scope, depending on the issuing // region's successors. for scc in sccs.depth_first_search(issuing_region_scc) { <del> // 1. Via member constraints </del> <ins> // 1. Via applied member constraints </ins> // // The issuing region can flow into the choice regions, and they are either: // - placeholders or free regions themselves, // - or also transitively outlive a free region. // <del> // That is to say, if there are member constraints here, the loan escapes the function // and cannot go out of scope. We can early return. if self.regioncx.scc_has_member_constraints(scc) { return; </del> <ins> // That is to say, if there are applied member constraints here, the loan escapes the // function and cannot go out of scope. We could early return here. // // For additional insurance via fuzzing and crater, we verify that the constraint's min // choice indeed escapes the function. In the future, we could e.g. turn this check into // a debug assert and early return as an optimization. for constraint in self.regioncx.applied_member_constraints(scc) { if universal_regions.is_universal_region(constraint.min_choice) { return; } </ins> } // 2. Via regions that are live at all points: placeholders and free regions.

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
let mut path_segments = path_segments.clone(); path_segments.push(ast::PathSegment::from_ident(ident)); <ins> let alias_import = if let NameBindingKind::Import { import, .. } = name_binding.kind && let ImportKind::ExternCrate { source: Some(_), .. } = import.kind && import.parent_scope.expansion == parent_scope.expansion { true } else { false }; </ins> let is_extern_crate_that_also_appears_in_prelude = name_binding.is_extern_crate() && lookup_ident.span.at_least_rust_2018(); <del> if !is_extern_crate_that_also_appears_in_prelude { </del> <ins> if !is_extern_crate_that_also_appears_in_prelude || alias_import { </ins> // add the module to the lookup if seen_modules.insert(module.def_id()) { if via_import { &mut worklist_via_import } else { &mut worklist }

Discussion:
Some build environments (e.g. Chromium (), Bazel) may generate crate names based on names of build targets. While this results in globally-unique () crate names, it results in long and quite unwieldy crate names. Both Chromium and Blaze provide a macro to help working with such crate names: The macro usage above expands to something like: Unfortunately, it seems that some diagnostics keep referring to the long and unwieldy name. () see () globally-unique crate names = within a given build tree No response More detailed repro can be found below:
Is this something worth fixing? Is the original crate name worth preferring over the aliased name in some scenarios?
BTW: I also want to note/highlight that I am not able to repro the problem without using . For example (same files):
/cc
Change:
if self.type_is_fat_ptr(src.ty) { match (src.value, self.type_is_fat_ptr(dest_ty)) { (Value::ByRef { .. }, _) | <ins> // pointers to extern types (Value::ByVal(_),_) | // slices and trait objects to other slices/trait objects </ins> (Value::ByValPair(..), true) => { let valty = ValTy { value: src.value,

Discussion:
At This is used by is_null() Backtrace: cc solson/miri
Minimal repro:
Change:
<ins> // edition:2018 struct S<'a>(&'a i32); impl<'a> S<'a> { async fn new(i: &'a i32) -> Result<Self, ()> { //~^ ERROR: `async fn` Ok(S(&22)) } } fn main() {} </ins>

Discussion:
Following the improvement for the diagnostic of the error reported in this issue , it would be nice (depending on how is prioritized) to have the same error message when instead of returning the function returns . When is returned I get a nice error message (on rustc 1.47): But if is used I get: with no suggestion to spell the type.
remove-assignment feel free to re-claim if you are working on this.
Change:
let tcx = self.infcx.tcx; let (def_id, substs) = match *placeholder_trait_predicate.trait_ref.self_ty().kind() { <del> ty::Alias(_, ty::AliasTy { def_id, substs, .. }) => (def_id, substs), </del> <ins> ty::Alias(ty::Projection | ty::Opaque, ty::AliasTy { def_id, substs, .. }) => { (def_id, substs) } </ins> _ => { span_bug!( obligation.cause.span,

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This might also be related to cc
label F-inherentassociatedtypes claim
Change:
_a = (0); //~ ERROR unnecessary parentheses around assigned value _a += (1); //~ ERROR unnecessary parentheses around assigned value <ins> let(mut _a) = 3; //~ ERROR unnecessary parentheses around pattern let (mut _a) = 3; //~ ERROR unnecessary parentheses around pattern let( mut _a) = 3; //~ ERROR unnecessary parentheses around pattern let(_a) = 3; //~ ERROR unnecessary parentheses around pattern let (_a) = 3; //~ ERROR unnecessary parentheses around pattern let( _a) = 3; //~ ERROR unnecessary parentheses around pattern </ins> let _a = baz!(3, 4); let _b = baz!(3); }

Discussion:
Rustc suggests incorrect fixes for #[warn(unusedparens)] for these patterns. No response Rustc version: (the same issue with the stable 1.73.0 rustc). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
"checksum cmake 0.1.26 (registry+https://github.com/rust-lang/crates.io-index)" = "357c07e7a1fc95732793c1edb5901e1a1f305cfcf63a90eb12dbd22bdb6b789d" "checksum commoncrypto 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d056a8586ba25a1e4d61cb090900e495952c7886786fc55f909ab2f819b69007" "checksum commoncrypto-sys 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1fed34f46747aa73dfaa578069fd8279d2818ade2b55f38f22a9401c7f4083e2" <del> "checksum compiletest_rs 0.2.10 (registry+https://github.com/rust-lang/crates.io-index)" = "2741d378feb7a434dba54228c89a70b4e427fee521de67cdda3750b8a0265f5a" </del> <ins> "checksum compiletest_rs 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)" = "86f4663adfd113e17109c35c2067194eca782a5baf9c90f4696ca13d04631adb" </ins> "checksum core-foundation 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)" = "5909502e547762013619f4c4e01cc7393c20fe2d52d7fa471c1210adb2320dc7" "checksum core-foundation-sys 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)" = "bc9fb3d6cb663e6fd7cf1c63f9b144ee2b1e4a78595a0451dd34bff85b9a3387" "checksum crossbeam 0.2.10 (registry+https://github.com/rust-lang/crates.io-index)" = "0c5ea215664ca264da8a9d9c3be80d2eaf30923c259d03e870388eb927508f97"

Discussion:
branch: master Compiling cargometadata v0.2.3 Compiling clippylints v0.0.166 (file:///home/ryan/git/rust/src/tools/clippy/clippylints) error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: aborting due to previous error error: aborting due to previous error error: Could not compile . warning: build failed, waiting for other jobs to finish... error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed This failure is expected (see ) Build completed successfully in 1:46:49
Everything is actually fine, as you can see by the last two lines of the log. I hope to remove the error log if the failure is expected in the future, but not sure yet how best to do that.
Is it related to rust-lang-nursery/rust-clippy?
Change:
<ins> // Check that statically linked binary executes successfully // with RLIMIT_NOFILE resource lowered to zero. Regression // test for issue #96621. // // run-pass // dont-check-compiler-stderr // only-linux // no-prefer-dynamic // compile-flags: -Ctarget-feature=+crt-static -Crpath=no #![feature(exit_status_error)] #![feature(rustc_private)] extern crate libc; use std::os::unix::process::CommandExt; use std::process::Command; fn main() { let mut args = std::env::args(); let this = args.next().unwrap(); match args.next().as_deref() { None => { let mut cmd = Command::new(this); cmd.arg("Ok!"); unsafe { cmd.pre_exec(|| { let rlim = libc::rlimit { rlim_cur: 0, rlim_max: 0, }; if libc::setrlimit(libc::RLIMIT_NOFILE, &rlim) == -1 { Err(std::io::Error::last_os_error()) } else { Ok(()) } }) }; let output = cmd.output().unwrap(); println!("{:?}", output); output.status.exit_ok().unwrap(); assert!(output.stdout.starts_with(b"Ok!")); } Some(word) => { println!("{}", word); } } } </ins>

Discussion:
polls to the standard file descriptors on startup; if they are closed, it attempts to reopen them to . If  is too low, the polling (or opening) will cause an abort. The could be checked ahead of time. I tried this Docker configuration I expected to see this happen: Successful execution Instead, this happened: Process aborted It most recently worked on: Rust 1.47 Rust 1.48 and forward. modify labels: +regression-from-stable-to-stable -regression-untriaged
Are file descriptors 0-2 open at the time of the abort? Edit, ah, I see this is a limitation of , not of the process being incorrectly spawned. This could be solved by a fallback to calling on individual fds if poll doesn't work.
We're happy to review a patch for this. (E.g. falling back to fstat if poll returns EINVAL.)
Change:
// except according to those terms. trait I {} <del> type K = I; //~ ERROR: reference to trait </del> <ins> type K = I; </ins> impl K for int {} //~ ERROR: `K` is not a trait <ins> //~^ NOTE: `type` aliases cannot be used for traits </ins> fn main() {}

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
<ins> trait TraitA { const VALUE: usize; } struct A; impl TraitA for A { const VALUE: usize = 0; } trait TraitB { type MyA: TraitA; const VALUE: usize = Self::MyA::VALUE; } struct B; impl TraitB for B { //~ ERROR not all trait items implemented, missing: `MyA` type M   = A; //~ ERROR type `M` is not a member of trait `TraitB` } fn main() { let _ = [0; B::VALUE]; } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
This regressed in .
cc
triage: already has fix in pipeline. P-high. removing nomination label.
Change:
pub use crate::macros::{assert_matches, debug_assert_matches}; } <ins> #[unstable(feature = "cfg_match", issue = "115585")] pub use crate::macros::cfg_match; </ins> #[macro_use] mod internal_macros;

Discussion:
In: https://crater- https://crater-
mean to ping instead
The macro was originally named to avoid this situation (). I don't know if it is possible to solve this issue in the compiler so I will just revert the changes.
cc maybe you have ideas
This may just be acceptable breakage - I don't know that we need to revert things. I would wait on libs-api weighing in, impact is pretty minimal in crater.
the problem is that this adds it to the prelude. maybe there's a way to add it somewhere where it doesn't get to the prelude? for example by making it a macro 2.0.
Looks like a good short-term solution. Preferably, it would be nice to have prelude support with a different name or an acceptable breakage.
FWIW, I can take care of fixing too, if that makes things simpler. I don't know about the eponymous crate, however. The funny thing is that I am working around the current issue by renaming as , so if this were to become the decision here please let me know so that I pick some third name
Change:
<ins> // aux-build:rmeta-meta.rs // no-prefer-dynamic // build-fail // Check that we do not ICE when we need optimized MIR but it is missing. extern crate rmeta_meta; fn main() { rmeta_meta::missing_optimized_mir(); } </ins>

Discussion:
The following scenario used to work fine 1.25.0: This would create two .bc files that could be linked together into a program, but when I try this on 1.26.{0,1,2} the compiler crashes like so:
Possibly dupe/related to ?
Yea I think this is a dupe, handling over there
The issue you mention seems to have something to do with impl trait (and looks like it goes away when the use is removed?) , whereas the issue I posted here crashes with even the simplest rust code. Are they really the same?
Hmm... you're right. I mean impl Trait in the other issue is just the trigger, the cause is in a normal function calling another one, but here you have another crate
I've discovered that if I tell the compiler to emit another type along with like this issue goes away. It makes me suspect this piece of code in : I'm wondering if by not running the code-gen or linking when outputting the metadata is causing this.
Triage: still repros:
Since , doesn't include optimized MIR, so produced rlib cannot be used to perform codegen. It would be nice to detect that particular situtation and produce more meaningful error describing that this is unsupported.
PR with fix:
Change:
inverse_memory_index.into_iter().map(|it| it.index() as u32).collect() }; let size = min_size.align_to(align.abi); <ins> // FIXME(oli-obk): deduplicate and harden these checks if size.bytes() >= dl.obj_size_bound() { return None; } </ins> let mut layout_of_single_non_zst_field = None; let mut abi = Abi::Aggregate { sized }; // Try to make this a Scalar/ScalarPair.

Discussion:
rustc generally detects when a static type is larger than bytes, giving an error that + 10x80000000isize::MAX + 1`): (The is to ensure that an object of size is actually created on the stack.) This is clearly unsound, since it breaks the size invariant of , and since third-party crates may depend on types being no larger than for soundness. However, it's nontrivial to observe unexpected behavior from this using only safe APIs in the standard library, since placing the overlarge type within any other type, even a wrapper, will result in a compile error as expected, and the standard APIs tend to refer to when creating a slice from a reference.
Wow, good catch! Looks like we're doing the check before rounding up to the next multiple of alignment? That's bad.
Change:
error[E0308]: mismatched types <del> --> $DIR/chain-method-call-mutation-in-place.rs:3:5 </del> <ins> --> $DIR/chain-method-call-mutation-in-place.rs:2:23 | LL |     let x: Vec<i32> = vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i); |            --------   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `Vec<i32>`, found `()` |            | |            expected due to this | = note: expected struct `Vec<i32>` found unit type `()` note: method `sort_by_key` modifies its receiver in-place, it is not meant to be used in method chains. --> $DIR/chain-method-call-mutation-in-place.rs:2:71 | LL |     let x: Vec<i32> = vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i); |                                                                       ^^^^^^^^^^^ this call modifies its receiver in-place error[E0599]: no method named `sort` found for unit type `()` in the current scope --> $DIR/chain-method-call-mutation-in-place.rs:3:72 | LL |     vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort(); |                                                                        ^^^^ method not found in `()` | note: method `sort_by_key` modifies its receiver in-place, it is not meant to be used in method chains. --> $DIR/chain-method-call-mutation-in-place.rs:3:53 | LL |     vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort(); |                                                     ^^^^^^^^^^^ this call modifies its receiver in-place error[E0308]: mismatched types --> $DIR/chain-method-call-mutation-in-place.rs:7:5 </ins> | LL | fn foo(mut s: String) -> String { |                          ------ expected `String` because of return type

Discussion:
In long method chains we might inadvertently call a method that is not meant to be chained. When this happens, the most likely error to occur is a type error involving . We should instead look if the rhs expression is a method chain and look at all the chained call's type to find where is introduced. Given Ideally the output would be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I'd like to try working on this :) claim
Change:
/// Inline asm operand type must be `Sized`. InlineAsmSized, /// `[T, ..n]` implies that `T` must be `Copy`. <del> RepeatVec, </del> <ins> /// If the function in the array repeat expression is a `const fn`, /// display a help message suggesting to move the function call to a /// new `const` item while saying that `T` doesn't implement `Copy`. RepeatVec(bool), </ins> /// Types of fields (other than the last, except for packed structs) in a struct must be sized. FieldSized {

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim
Change:
"hex", "log", "num-traits", <del> "rand 0.6.1", </del> <ins> "rand 0.7.0", </ins> "rustc-workspace-hack", "rustc_version", "shell-escape",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
triage: P-medium. Unnominating.
Change:
return; } <del> let node_path = tcx.item_path_str(tcx.hir.local_def_id(source.item_id())); </del> <ins> let node_path = item_path::with_forced_impl_filename_line(|| { // see notes on #41697 below tcx.item_path_str(tcx.hir.local_def_id(source.item_id())) }); </ins> dump_matched_mir_node(tcx, pass_num, pass_name, &node_path, disambiguator, source, mir); for (index, promoted_mir) in mir.promoted.iter_enumerated() {

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is