jiebi/CodeConvo huggingface dataset:
Change:
let mut place_ty = PlaceTy::from_ty(self.body.local_decls[place.local].ty); <del> if place.projection.is_empty() { if let PlaceContext::NonMutatingUse(NonMutatingUseContext::Copy) = context { let tcx = self.tcx(); let trait_ref = ty::TraitRef { def_id: tcx.lang_items().copy_trait().unwrap(), substs: tcx.mk_substs_trait(place_ty.ty, &[]), }; // To have a `Copy` operand, the type `T` of the // value must be `Copy`. Note that we prove that `T: Copy`, // rather than using the `is_copy_modulo_regions` // test. This is important because // `is_copy_modulo_regions` ignores the resulting region // obligations and assumes they pass. This can result in // bounds from `Copy` impls being unsoundly ignored (e.g., // #29149). Note that we decide to use `Copy` before knowing // whether the bounds fully apply: in effect, the rule is // that if a value of some type could implement `Copy`, then // it must. self.cx.prove_trait_ref( trait_ref, location.to_locations(), ConstraintCategory::CopyBound, ); } } </del> for elem in place.projection.iter() { if place_ty.variant_index.is_none() { if place_ty.ty.references_error() {

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 : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
use rustc_hir as hir; use rustc_hir::lang_items::LangItem; use rustc_hir::{is_range_literal, Node}; <ins> use rustc_middle::lint::in_external_macro; </ins> use rustc_middle::ty::adjustment::AllowTwoPhase; use rustc_middle::ty::{self, AssocItem, Ty, TypeAndMut}; use rustc_span::symbol::sym;

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
// We stop at any delimiter so we can try to recover if the user // uses an incorrect delimiter. let (tts, res) = self.parse_token_trees(/* is_delimited */ true); <del> if let Err(mut errs) = res { // If there are unclosed delims, see if there are diff markers and if so, point them // out instead of complaining about the unclosed delims. let mut parser = crate::stream_to_parser(self.string_reader.sess, tts, None); let mut diff_errs = vec![]; while parser.token != token::Eof { if let Err(diff_err) = parser.err_diff_marker() { diff_errs.push(diff_err); } parser.bump(); } if !diff_errs.is_empty() { errs.iter_mut().for_each(|err| { err.delay_as_bug(); }); return Err(diff_errs); } return Err(errs); </del> <ins> if let Err(errs) = res { return Err(self.unclosed_delim_err(tts, errs)); </ins> } // Expand to cover the entire delimited token tree

Discussion:
Unmatched delimiters are hard to deal with by taking consideration of surrounding code because they actually occur during lexing. Still, it'd be nice if we detected some common sources of issues like this one. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
) exit_code = 0 <ins> success_word = "successfully" </ins> try: bootstrap(args) except (SystemExit, KeyboardInterrupt) as error:

Discussion:
do you have time to fix this regression? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Yes, will do claim
Change:
key!(supported_sanitizers, SanitizerSet)?; key!(default_adjusted_cabi, Option<Abi>)?; <ins> if base.is_builtin { // This can cause unfortunate ICEs later down the line. return Err(format!("may not set is_builtin for targets not built-in")); } </ins> // Each field should have been read using `Json::remove_key` so any keys remaining are unused. let remaining_keys = obj.as_object().ok_or("Expected JSON object for target")?.keys(); Ok((

Discussion:
I'm new to Rust and I try to compile a project with a (I'm also new to that project and that project is not well organized.) when I use Makefile to make, the process of making executes and it reports it's a bug, so I'm here. I'm fresh here so if there is some information I don't provide, please tell me and I will try my best to provide it. Thank you! <!-- 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. --here I couldn't provide the example code since I don't really know the minimal set of code to be compiled the source code of the repo is in rustc should be in the nightly mode rust code is in the rust/sel4-rust/ in directory will execute in directory <!-- 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
Thank you for filing an issue! When I click that linked you posted, I get an error. Is it set that other people can view it?
Sorry, I have fixed the typo. Now the link should be right.(next time I will be more careful to check my issue)
The root of the issue is in the target definition file that the repository contains, however there are three other bugs that can be fixed in rustc: should not ICE when invalid external targets are being used; should report the actual target name/file in the error message, not the LLVM target name; target files are allowed to set the property.
The minimal target file to reproduce: with
( is a 404 )
Change:
"a list of arguments to pass to llvm (space separated)"), save_temps: bool = (false, parse_bool, "save all temporary output files during compilation"), <del> no_rpath: bool = (false, parse_bool, "disables setting the rpath in libs/exes"), </del> <ins> rpath: bool = (false, parse_bool, "set rpath values in libs/exes"), </ins> no_prepopulate_passes: bool = (false, parse_bool, "don't pre-populate the pass manager with a list of passes"), no_vectorize_loops: bool = (false, parse_bool,

Discussion:
Followup to and . Can we completely eliminate our usage of rpath? Doing so would make our linkage more consistent across platforms since it doesn't work on windows. Nominating.
I think that the largest difficulty for this is that we build dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path). If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
If we defaulted to static linking then there would it would be easier to justify making people use LDLIBRARYPATH when they opt in to dylibs.
The only consideration that I have about static linking is that you'll install 5 copies of (as opposed to 3): with static linking rustdoc rustc rustpkg without static linking That being said, our distributions are already pretty big, so maybe this isn't much of a concern? I agree though that if we statically linked everything then we could easily take this route of action
IMO this is a concern. What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically ().
Another use case for this came up on IRC. If you've got a rust installed locally in , then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1 , this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).
Accepted for 1.0, P-backcompat-lang.
Rust now builds and passes tests with . This feature could be disabled by default or completely removed, with as a suggestion for those who want to use a dynamically linked in their home directory on *nix.
Change:
<ins> fn main() { foo::/* definitely not harmful comment */(123, "foo") -> (u32); //~ ERROR: expected type, found `123` //~^ NOTE: while parsing this parenthesized list of type arguments starting //~^^ NOTE: expected type } </ins>

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
.extend( // Group the return ty with its def id, if we had one. entry.return_ty.map(|ty| { <del> (tcx.require_lang_item(LangItem::FnOnce, None), ty) </del> <ins> (tcx.require_lang_item(LangItem::FnOnceOutput, None), ty) </ins> }), ); }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: cannot get associated-item of ', 'error: internal compiler error: cannot get associated-item of ' File: --another one caused by 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: [associated_item] computing associated item data for [typeck] type-checking [analysis] running analysis passes on this crate --
fyi
not caused by that, only exposed by it. The issue is a typo using instead of in diagnostic code, getting the wrong and then attempting to treat as an associated item
Change:
<ins> error[E0223]: ambiguous associated type --> $DIR/issue-78622.rs:5:5 | LL |     S::A::<f> {} |     ^^^^^^^^^ help: use fully-qualified syntax: `<S as Trait>::A` error: aborting due to previous error For more information about this error, try `rustc --explain E0223`. </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. --<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Output on 1.46: modify labels: +regression-from-stable-to-stable
Assigning and removing as in the prioritization working group.
Change:
<del> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2013-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> extern crate num;

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (trivial update due to language changes): OK OK (sent agreement to by email) OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
Yes I am a MoCo employee, you don't have to worry about me for this or future benchmark relicensing issues.
Thanks On Jun 7, 2014 5:06 AM, "TeXitoi" wrote:
Change:
<ins> error[E0277]: `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely --> $DIR/issue-67893.rs:9:5 | LL | fn g(_: impl Send) {} |              ---- required by this bound in `g` ... LL |     g(issue_67893::run()) |     ^ `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely | ::: $DIR/auxiliary/issue_67893.rs:7:20 | LL | pub async fn run() { |                    - within this `impl std::future::Future` | = help: within `impl std::future::Future`, the trait `std::marker::Send` is not implemented for `std::sync::MutexGuard<'_, ()>` = note: required because it appears within the type `for<'r, 's, 't0, 't1, 't2, 't3> {std::future::ResumeTy, std::sync::Arc<std::sync::Mutex<()>>, &'r std::sync::Mutex<()>, std::result::Result<std::sync::MutexGuard<'s, ()>, std::sync::PoisonError<std::sync::MutexGuard<'t0, ()>>>, &'t1 std::sync::MutexGuard<'t2, ()>, std::sync::MutexGuard<'t3, ()>, (), impl std::future::Future}` = note: required because it appears within the type `[static generator@issue_67893::run::{{closure}}#0 for<'r, 's, 't0, 't1, 't2, 't3> {std::future::ResumeTy, std::sync::Arc<std::sync::Mutex<()>>, &'r std::sync::Mutex<()>, std::result::Result<std::sync::MutexGuard<'s, ()>, std::sync::PoisonError<std::sync::MutexGuard<'t0, ()>>>, &'t1 std::sync::MutexGuard<'t2, ()>, std::sync::MutexGuard<'t3, ()>, (), impl std::future::Future}]` = note: required because it appears within the type `std::future::from_generator::GenFuture<[static generator@issue_67893::run::{{closure}}#0 for<'r, 's, 't0, 't1, 't2, 't3> {std::future::ResumeTy, std::sync::Arc<std::sync::Mutex<()>>, &'r std::sync::Mutex<()>, std::result::Result<std::sync::MutexGuard<'s, ()>, std::sync::PoisonError<std::sync::MutexGuard<'t0, ()>>>, &'t1 std::sync::MutexGuard<'t2, ()>, std::sync::MutexGuard<'t3, ()>, (), impl std::future::Future}]>` = note: required because it appears within the type `impl std::future::Future` = note: required because it appears within the type `impl std::future::Future` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Follow-up of Consider this example: It emits the stderr on my local (x86_64-unknown-linux-gnu): But on some other environment on CI, e.g. or , it emits it with a tiny difference: It's ideal to have the same diagnostics on all the environment. See also:
s shouldn't be leaked in user output.
Yeah, other places look like: Perhaps we emit accidentally in somewhere.
that makes me think that we probably have some instead of somewhere.
The relevant code is: I don't find any difference between here and similar places yet. thoughts?
the place to look at is: CC The same applies to closures, but we are likely not displaying them this way anywhere (or we've just gotten lucky).
Change:
#[derive(Debug, Clone, PartialEq, Eq)] enum FromSecsErrorKind { <del> // Value is not a finite value (either infinity or NaN). </del> <ins> // Value is not a finite value (either + or - infinity or NaN). </ins> NonFinite, // Value is too large to store in a `Duration`. Overflow, <del> // Value is less than `0.0`. Underflow, </del> <ins> // Value is negative. Negative, </ins> }

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
assert_eq!(prefix, parse_prefix(r"/?C:windowssystem32notepad.exe")); assert_eq!(prefix, parse_prefix(r"?/C:windowssystem32notepad.exe")); } <ins> // See #93586 for more infomation. #[test] fn test_windows_prefix_components() { use crate::path::Path; let path = Path::new("C:"); let mut components = path.components(); let drive = components.next().expect("drive is expected here"); assert_eq!(drive.as_os_str(), OsStr::new("C:")); assert_eq!(components.as_path(), Path::new("")); } </ins>

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. --This code panics on Windows: According to the documentation for , it should either succeed or return . Instead, it panics due to an out-of-range index: <!-- 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. --: The bug is also present in nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I can confirm this. The problem originates in . A minimal example:
It seems that the in causes the issue, I'll try to fix.
claim