jiebi/CodeConvo huggingface dataset:
Change:
Once this is done, build/$ARCH/stage1 contains a usable compiler.", ); } <del> "check" => { </del> <ins> "check" | "c" => { </ins> subcommand_help.push_str( "n Arguments:

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // 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. #![feature(rustc_attrs)] #[rustc_mir] fn test1(f: f32) -> bool { // test that we properly promote temporaries to allocas when a temporary is assigned to // multiple times (assignment is still happening once ∀ possible dataflows). !(f.is_nan() || f.is_infinite()) } fn main() { assert_eq!(test1(0.0), true); } </ins>

Discussion:
In MIR we want values to be SSA, however ensuring that constraint in trans (i.e. in TempRef) is wrong, I think. Namely, for code like this: we will generate following MIR (graphviz version, because easier to visualise): ! which will result in Note how we assign twice, but the two branches are fully disjoint, and thus, for the purposes of data-flow is still SSA, but for the purposes of translator is assigned multiple times. If we want s to stay across translation of the whole function, we will need something like a in the MIR. cc
Another option would be to convert these temporaries into lvalues (i.e. variables). Could it be that the unfinished is supposed to do just that?
I am confused. We do not require temps to be SSA, either in Mir or trans... But in trans we optimize in those cases where we can (I.e., where temps are SSA). Right?
suggests they are SSA with borrowing and mutation possible. Might be me misinterpreting what SSA means, but what I mean is that these are not supposed to be assigned more than once, for some definitions of once.
I see. Yes, ok, I agree that comment was in error. I think though that you probably ought to update it in :) I would still expect temps to be "DSA" -- which afaik I just made up -- that is, no two writes can reach one another without exiting the "live scope" of the temporary, but I don't know that it's an important property. FWIW I think SSA usually implies that values are "pure values", i.e., you can't take their address and mutate them. But I know what you mean in any case.
er, ought to have updated it
I’ll keep updating the comment in mind in whatever PR that comes next.
Change:
/// assert!(!(0.0..).contains(&f32::NAN)); /// assert!(!(f32::NAN..).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

Discussion:
I tried this code: Also godbolt link I expected to see this happen: I was trying this code to see what kind of assemble the compilers makes. I tried different optimize levels. I see with optimize levels and , that the bits are still there but not used in the function. function is self takes about 5 instructions and the code about 40 instruction, which is dead code. Instead, this happened: bits removed in all the optimize levels. I was using a similar code on a embedded device. FYI: It also happens with . Remove the before 247. I see this happen on stable and nightly both for x86_64 and thumbv6/v7.
This is, unfortunately, well known. and aren't necessarily smaller 'll be optimized out in (which is opt-level=2).
Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.
maybe to clarify. With opt_level the assembly of the generated function is fine and optimized. But the bits are not removed and not used. so I am not sure if will help in this case.
does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the output to just one function.
Change:
"the `#[naked]` attribute  is an experimental feature", cfg_fn!(naked_functions))), <del> ("target_feature", Normal, Ungated), </del> <ins> ("target_feature", Whitelisted, Ungated), </ins> ("export_name", Whitelisted, Ungated), ("inline", Whitelisted, Ungated), ("link", Whitelisted, Ungated),

Discussion:
Given this code: it compiles as: How odd!
Not technically a regression but this needs to be fixed before 1.27 hits stable, so tagging as a nightly regression

Given: and you'll see: But that's not right! Only the original crate should need this directive, and it indeed has such a directive.
Change:
<ins> error[E0038]: the trait `Foo` cannot be made into an object --> $DIR/inference_var_self_argument.rs:5:5 | LL |     async fn foo(self: &dyn Foo) { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Foo` cannot be made into an object | note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/inference_var_self_argument.rs:5:14 | LL | trait Foo { |       --- this trait cannot be made into an object... LL |     async fn foo(self: &dyn Foo) { |              ^^^ ...because method `foo` is `async` = help: consider moving `foo` to another trait error[E0307]: invalid `self` parameter type: &dyn Foo --> $DIR/inference_var_self_argument.rs:5:24 | LL |     async fn foo(self: &dyn Foo) { |                        ^^^^^^^^ | = note: type of `self` must be `Self` or a type that dereferences to it = help: consider changing to `self`, `&self`, `&mut self`, `self: Box<Self>`, `self: Rc<Self>`, `self: Arc<Self>`, or `self: Pin<P>` (where P is one of the previous types except `Self`) error: aborting due to 2 previous errors Some errors have detailed explanations: E0038, E0307. For more information about an error, try `rustc --explain E0038`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()', 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()' File: --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: [typeck] type-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in module [analysis] running analysis passes on this crate --
Also ices in Rust 2021 in case anybody was wondering. Further reduced:
(see below)
It's of course :upsidedownface:
fyi
Change:
packages: &[&str], features: Option<&[&str]>, manifest_path: Option<&str>, <ins> filters: &[&str], </ins> ) -> bool { let mut command = Command::new(cargo_path); command.arg("test");

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
#    "analysis", #    "src", #    "wasm-component-ld", <ins> #    "miri", "cargo-miri" # for dev/nightly channels </ins> #] # Verbosity level: 0 == not verbose, 1 == verbose, 2 == very verbose, 3 == print environment variables on each rustc invocation

Discussion:
In the past, the default tools=[...] in included Miri. The default of building Miri was removed at and The latter is called “Do not build Miri by default”, and as it changes 1211 files obviously I do not follow what exactly it does. In any case, as in rustc-1.80.1-[build] # tools = [ "cargo", "clippy", "rustdoc", "rustfmt", "rust-analyzer", "rust-analyzer-proc-macro-srv", "analysis", "src", "rust-demangler", # if profiler = true] does not include miri, my understanding is that and should produce identical result (except for rust-analyzer-proc-macro-srv). But the first does lead to installing Miri, while the second skips installing Miri. As my observation is that now Miri is built by default (is part of the implicit tools=[…]), in tools= should indclude miri. To be precise the first ./configure I ran against rustc-1.79.0- and the second against rustc-1.80.1-
That PR shipped with Rust 1.66 so I'm not sure why you are linking it when you seem to be intending to report a change from Rust 1.79 to Rust 1.80.
I am not reporting a changbe between 1.79 and 1.80. I am saying that old Rust versions built Miri by default (miri was in the implicit tools=[]), then it was removed from tools=[], and now miri is again in the implicit tools=[], but not in [...]
The latter is called "Make miri a subtree instead of a submodule", which should give you an idea of why it changes so many files. ;) Cc ; I don't know if this was a deliberate change or not or how the implicit "tools" array is even computed. Miri is a nightly-only tool so we probably do not want it to be built implicitly on stable.
For dev/nightly channels, we simply build every tool by default: If channel isn't dev/nightly, we only build tools are are marked as and (although cargo-miri is) Miri isn't one of them.
Okay so if the sample is supposed to show the default it should show both of these, presumably?
Done that in ()
Change:
use rustc_target::spec::abi; use rustc_trait_selection::traits; use rustc_trait_selection::traits::astconv_object_safety_violations; <del> use rustc_trait_selection::traits::error_reporting::report_object_safety_error; </del> <ins> use rustc_trait_selection::traits::error_reporting::{ report_object_safety_error, suggestions::NextTypeParamName, }; </ins> use rustc_trait_selection::traits::wf::object_region_bounds; use smallvec::SmallVec;

Discussion:
One of the big problems with the 2015-style trait object syntax (no ) was that users often write things like when what they really meant was . Back then, the error message would more often than not be some inscrutable message about , which would send them on a wild goose chase of adding bounds everywhere they could think of, leading to even more inscrutable messages. Now, the error message is clearer: it tells users they need to add for a trait object type. However, I find in many cases (most cases?) this is not what users actually want - what they actually want is the blanket impl. It would be helpful to have a note suggesting the correct syntax for a blanket impl, or better yet just presenting both correct syntaxes (impl for trait object and blanket impl) on equal footing and making it clear the difference between them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I work to reproduce this issue and start to understand what type of check we need to do, and in particular the work that we need to do is the following one: If the traits are local traits we can perform the suggestion of the blanket impls, for example in the following code But we need to skip the following suggestion in case we are using not local traits, like the following code here
Change:
const ENTRY_LIMIT: u32 = 901; // FIXME: The following limits should be reduced eventually. <del> const ISSUES_ENTRY_LIMIT: u32 = 1673; </del> <ins> const ISSUES_ENTRY_LIMIT: u32 = 1672; </ins> const EXPECTED_TEST_FILE_EXTENSIONS: &[&str] = &[ "rs",     // test source files

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
<ins> // run-pass // Test a ZST enum whose dicriminant is ~0i128. This caused an ICE when casting to a i32. #[derive(Copy, Clone)] enum Nums { NegOne = -1, } const NEG_ONE_I8: i8 = Nums::NegOne as i8; const NEG_ONE_I16: i16 = Nums::NegOne as i16; const NEG_ONE_I32: i32 = Nums::NegOne as i32; const NEG_ONE_I64: i64 = Nums::NegOne as i64; const NEG_ONE_I128: i128 = Nums::NegOne as i128; #[inline(never)] fn identity<T>(t: T) -> T { t } fn test_as_arg(n: Nums) { assert_eq!(-1i8, n as i8); assert_eq!(-1i16, n as i16); assert_eq!(-1i32, n as i32); assert_eq!(-1i64, n as i64); assert_eq!(-1i128, n as i128); } fn main() { let kind = Nums::NegOne; assert_eq!(-1i8, kind as i8); assert_eq!(-1i16, kind as i16); assert_eq!(-1i32, kind as i32); assert_eq!(-1i64, kind as i64); assert_eq!(-1i128, kind as i128); assert_eq!(-1i8, identity(kind) as i8); assert_eq!(-1i16, identity(kind) as i16); assert_eq!(-1i32, identity(kind) as i32); assert_eq!(-1i64, identity(kind) as i64); assert_eq!(-1i128, identity(kind) as i128); test_as_arg(Nums::NegOne); assert_eq!(-1i8, NEG_ONE_I8); assert_eq!(-1i16, NEG_ONE_I16); assert_eq!(-1i32, NEG_ONE_I32); assert_eq!(-1i64, NEG_ONE_I64); assert_eq!(-1i128, NEG_ONE_I128); } </ins>

Discussion:
Compiling this code on : results in ICE. Casting to anything smaller than /(, , , , , etc) also results in ICE. Casting to anything same size or larger(, , , , etc) works fine. Positive discriminant values also work fine. Version of rustc: (on rust playground) Compiler flags listed as used:
indicates that this was injected in Rust 1.40
Thanks for the report! Please always include the ICE message. This time, it seems to be
Change:
// Ensure indexes are also not malformed. if start_index > end_index || end_index > source_len - 1 { debug!("find_width_of_character_at_span: source indexes are malformed"); <del> return 0; </del> <ins> return 1; </ins> } let src = local_begin.sf.external_src.borrow();

Discussion:
This malformed code () hangs the compiler: Found by fuzzing with a . must be defined as a named-field struct (not a tuple struct or unit struct), although it can have 0 fields. must be the last token to produce the hang: No opening brace (note that braces are required for literals of named-field structs) No closing delimiters Not even a comment If I understand correctly, the hang occurs in LateResolutionVisitor, with never finishing (while calling various functions such as and ) This also hangs. I'm guessing it's the same bug. : with: <details</summary<p</p</detailsregressed nightly: nightly-2022-10-21 regressed commit: (PR ) label +regression-from-stable-to-nightly +I-hang <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I can not reproduce it with latest code, did I missed anything?
Great cactch Confirmed the error is only triggered by commit: The root cause is I changed the edge corner case in : We think won't return a span which outside of source file, so is a valid one, then will always return a valid span, and we get from when reaching the end of source. So, there is a loop in previous , which will run infinitely loop: Lucky, my another PR merged at last day, this PR refactored this function:
Verif, I no longer get a hang after rollup Do you want to add one or two of these as tests?
Yes, we'd better add a testcase for it. I'm thinking whether we sould in when reaching to the end of source, so that may get an error.
This testcase seems not easy to be : If so, the trigger point will do not exist,
label -I-prioritize
There's an alternative kind of annotation for patterns that should work for this case:
Change:
}; let msg = values <del> .and_then(|(predicate, _, normalized_ty, expected_ty)| { self.maybe_detailed_projection_msg( predicate, normalized_ty.into(), expected_ty.into(), ) </del> <ins> .and_then(|(predicate, _, normalized_term, expected_term)| { self.maybe_detailed_projection_msg(predicate, normalized_term, expected_term) </ins> }) .unwrap_or_else(|| format!("type mismatch resolving `{}`", predicate)); let mut diag = struct_span_err!(self.tcx.sess, obligation.cause.span, E0271, "{msg}");

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
use core::mem; use core::ptr; use core::slice as core_slice; <ins> use core::{u8, u16, u32}; </ins> use borrow::{Borrow, BorrowMut, ToOwned}; use boxed::Box;

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
<del> use super::{uabs, AllocId, InterpResult}; </del> <ins> use super::{AllocId, InterpResult}; </ins> use rustc_macros::HashStable; use rustc_target::abi::{HasDataLayout, Size};

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses 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. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
Symbol::intern("into_multi_foo"), MultiModifier(Box::new(expand_into_foo_multi))); reg.register_syntax_extension( <ins> Symbol::intern("noop_attribute"), MultiModifier(Box::new(expand_noop_attribute))); reg.register_syntax_extension( </ins> Symbol::intern("duplicate"), MultiDecorator(Box::new(expand_duplicate))); }

Discussion:
Hi! I'm trying to compile my Rocket/Diesel/R2d2 task management project, which has previously successfully compiled, and when I add the newest piece which relies on macros in some new/different way (sorry for vague, I'm new to rust) it starts failing to compile. Looking at the backtrace, the error seems to be in MacroExpander::expandinvoc. I expect it to have the same behavior as the simpler version of the route: which warns about unused query result on compile but successfully runs, builds the NewTask struct from url components, and inserts it into the database. it fails to compile during cargo run, and the same exact error shows during cargo check. I've pasted the whole command with outputs here: Check out my project's for the exact code where I get the bug. Check out my project's master branch at commit to see the functional version (requires a local postgresql instance and a DATABASEURL env variable in a env file).
I minimized down to nothing but 14 looping macros in order to squarely place the blame on a single culprit once and for all: A function that just loops surely cannot be responsible for dropping a , so the must be a bug in rustc. (I still rather doubt it is in though, but rather, in a function that gets inlined into it)
So... I mentioned in the other issue how terrifying of a concept I thought was. For the uninitiated, is a type alias for a with a in its variant, which acts like a ticking timebomb; it explodes if the error is ever dropped. Simply put, has some methods that you must never call on a . Do you see it? :wink:
Ha! Thank you for the digging That stray is really cheeky, ain't it?
I'll probably submit a PR; I'm just browsing around the existing test cases for plugins trying to glean "best practices." (I'm also trying to see if there's any test case that causes the other in the branch to blow up. I don't think there is since it appears that the full attribute gets parsed before it tries to expand .)