jiebi/CodeConvo huggingface dataset:
Change:
} fn get_cargo_sysroot() -> result::t<fs::path, str> { <del> result::ok(fs::connect(get_default_sysroot(),  ".cargo")) </del> <ins> let path = [get_default_sysroot(), libdir(), "cargo"]; check vec::is_not_empty(path); result::ok(fs::connect_many(path)) </ins> } fn get_cargo_root() -> result::t<fs::path, str> {

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
/// assert!( (3.0..f32::NAN).is_empty()); /// assert!( (f32::NAN..5.0).is_empty()); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_is_empty", since = "1.47.0")] pub fn is_empty(&self) -> bool { !(self.start < self.end)

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:
use crate::common; use crate::traits::*; use rustc_hir as hir; <ins> use rustc_middle::mir::interpret::ErrorHandled; </ins> use rustc_middle::mir::mono::MonoItem; use rustc_middle::mir::mono::{Linkage, Visibility}; use rustc_middle::ty;

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim
Change:
f: F, /// The current internal state to be passed to the closure next. <ins> #[unstable(feature = "core")] </ins> pub state: St, }

Discussion:
compiles without any error. Notably this isn't a regression from I noticed it because has a public field that has had no stability attribute from far before . However, that PR did pick up some structs with missing stability attributes, I'm unsure of the exact circumstances when fields will get the errors or when they will not.
As points out in this isn't a bug; I didn't realise that stability propagation literally just ignores , meaning is due to the on . Closing.
Change:
// contains a non-nullable pointer, then this value is used as the discriminator. // The test cases in this file make sure that something readable is generated for // this kind of types. <del> // If the non-empty variant contains a single non-nullable pointer than the whole // item is represented as just a pointer and not wrapped in a struct. // Unfortunately (for these test cases) the content of the non-discriminant fields // in the null-case is not defined. So we just read the discriminator field in // this case (by casting the value to a memory-equivalent struct). </del> enum MoreFields<'a> { Full(u32, &'a isize, i16),

Discussion:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.
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. static foo: i32 = 0; //~^ NOTE static variable defined here fn bar(foo: i32) {} //~^ ERROR static variables cannot be referenced in a pattern, use a `const` instead mod submod { pub static answer: i32 = 42; //~^ NOTE static variable defined here } use self::submod::answer; //~^ NOTE static variable imported here fn question(answer: i32) {} //~^ ERROR static variables cannot be referenced in a pattern, use a `const` instead fn main() { } </ins>

Discussion:
Rustc version: rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23)
Hmm, I am not sure if this is a bug or not. I can see it both ways.
As I understand, this error is related to the situation like this
Change:
/// have `'tcx` be free on this function so that we can talk about /// `K: TypeFoldable<TyCtxt<'tcx>>`.) fn enter_canonical_trait_query<K, R>( <del> &mut self, </del> <ins> self, </ins> canonical_key: &Canonical<'tcx, K>, operation: impl FnOnce(&ObligationCtxt<'_, 'tcx>, K) -> Result<R, NoSolution>, ) -> Result<CanonicalQueryResponse<'tcx, R>, NoSolution>

Discussion:
This used to compile and now ICEs: Compiles on Stable version: 1.70.0 Regressed in 1.71.0-beta.6 (2023-07-08 ) I guess it is , but this shouldn't be in beta? <details<summary<strongBacktrace</strong</summary<p</p</details
Bisection results: searched nightlies: from nightly-2023-05-20 to nightly-2023-07-14 regressed nightly: nightly-2023-06-25 searched commit range: regressed commit: ( -), cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
use std::gc::{Gc, GC}; <del> pub fn expand_expr(e: Gc<ast::Expr>, fld: &mut MacroExpander) -> Gc<ast::Expr> { </del> <ins> fn expand_expr(e: Gc<ast::Expr>, fld: &mut MacroExpander) -> Gc<ast::Expr> { </ins> match e.node { // expr_mac should really be expr_ext or something; it's the // entry-point for all syntax extensions.

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
assert!(b != "world"); ~~~~ <del> ### Vector types </del> <ins> ### Vector, Array, and Slice types </ins> <del> The vector type constructor represents a homogeneous array of values of a given type. A vector has a fixed size. (Operations like `vec.push` operate solely on owned vectors.) A vector type can be annotated with a _definite_ size, such as `[int, ..10]`. Such a definite-sized vector type is a first-class type, since its size is known statically. A vector without such a size is said to be of _indefinite_ size, and is therefore not a _first-class_ type. An indefinite-size vector can only be instantiated through a pointer type, such as `&[T]` or `Vec<T>`. The kind of a vector type depends on the kind of its element type, as with other simple structural types. </del> <ins> Rust has three different types for a list of items: </ins> <del> Expressions producing vectors of definite size cannot be evaluated in a context expecting a vector of indefinite size; one must copy the definite-sized vector contents into a distinct vector of indefinite size. </del> <ins> * `Vec<T>`, a 'vector' * `[T ..N]`, an 'array' * `&[T]`, a 'slice'. </ins> <del> An example of a vector type and its use: </del> <ins> A vector is a heap-allocated list of `T`. A vector has ownership over the data inside of it. It is also able to grow and change in size. It's important to note that `Vec<T>` is a library type, it's not actually part of the core language. </ins> <del> ~~~~ let v: &[int] = &[7, 5, 3]; let i: int = v[2]; assert!(i == 3); ~~~~ </del> <ins> An array has a fixed size, and can be allocated on either the stack or the heap. A slice is a 'view' into a vector or array. It doesn't own the data it points to, it borrows it. An example of each kind: ```{rust} let vec: Vec<int>  = vec![1, 2, 3]; let arr: [int, ..3] = [1, 2, 3]; let s: &[int]      = vec.as_slice(); ``` As you can see, the `vec!` macro allows you to create a `Vec<T>` easily. The `vec!` macro is also part of the standard library, rather than the language. </ins> <del> All in-bounds elements of a vector are always initialized, and access to a vector is always bounds-checked. </del> <ins> All in-bounds elements of vectors, arrays, and slices are always initialized, and access to a vector, array, or slice is always bounds-checked. </ins> ### Structure types

Discussion:
In , the type is referred to as an array and is done as an slice. A in the RFC also refers to as an array, as a slice and as a vector. However, and don't conform to it. I think it is a problem.
The documentation at I find particularly hard to follow.
Change:
// Reachable constants will be inlined into other crates // unconditionally, so we need to make sure that their // contents are also reachable. <del> hir::ItemKind::Const(_, init) => { </del> <ins> hir::ItemKind::Const(_, init) | hir::ItemKind::Static(_, _, init) => { </ins> self.visit_nested_body(init); }

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 couldn't I couldn't produce a single file example, as it seems the ICE is triggered when cross crate compilation is involved; i.e dumping the contents of into does not trigger the ICE. This seems like a regression of the feature as this previously worked on nightly of the 1.50 stable release. : : <!-- 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
While regression itself is related to the introduction of CTFE MIR, it seems this actually never worked correctly, with static ending up duplicated.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
I can't reproduce with the latest nightly and cargo. Are there any further instructions for reproducing this?
Apologies, forgot to mention you'll need to add Or build for a target that does not have panic unwinding enabled by default.
(discussed in T-compiler meeting. This is an issue on stable, and might get a backport via . Re-opening to investigate details of what worked, what stopped working, what is fixed, and what is still broken.)
In the case reported here, one crate references static from another crate. During mono item collection, based on reachability determines whether it will link to item from an upstream crate or codegen it locally. When decision is made to codegen locally, it is followed by an assertion that optimized MIR is available to do so. In 1.50 static is non-reachable and codegenned locally. In 1.51 and 1.52 static is non-reachable, but the assertion fails since statics no longer use optimized MIR. In nightly, since , the static is reachable and linked to. The change seems safe for backporting to me.
Closing as the .
Change:
ti: TopInfo<'tcx>, ) -> Ty<'tcx> { let calc_side = |opt_expr: Option<&'tcx hir::Expr<'tcx>>| match opt_expr { <del> None => (None, None), </del> <ins> None => None, </ins> Some(expr) => { let ty = self.check_expr(expr); <del> // Check that the end-point is of numeric or char type. let fail = !(ty.is_numeric() || ty.is_char() || ty.references_error()); (Some(ty), Some((fail, ty, expr.span))) </del> <ins> // Check that the end-point is possibly of numeric or char type. // The early check here is not for correctness, but rather better // diagnostics (e.g. when `&str` is being matched, `expected` will // be peeled to `str` while ty here is still `&str`, if we don't // err ealy here, a rather confusing unification error will be // emitted instead). let fail = !(ty.is_numeric() || ty.is_char() || ty.is_ty_var() || ty.references_error()); Some((fail, ty, expr.span)) </ins> } }; <del> let (lhs_ty, lhs) = calc_side(lhs); let (rhs_ty, rhs) = calc_side(rhs); </del> <ins> let mut lhs = calc_side(lhs); let mut rhs = calc_side(rhs); </ins> if let (Some((true, ..)), _) | (_, Some((true, ..))) = (lhs, rhs) { // There exists a side that didn't meet our criteria that the end-point

Discussion:
currently throws E0029: while it should infer the constant to be . modify labels: +T-compiler +A-inference claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think this is incorrect. doesn't refer to a specific constant, it's just an abstract associated constant. works fine.
Hmm, does work, though. But does not. It does seem inconsistent that works and doesn't.
is just , so type inference should kick in here. In fact you can write and inference works just fine. The issue only happens when used in range patterns. I am prototyping a fix right now and it seems that the issue is just that E0029 check happens a little bit early (before unification is performed).
Change:
<ins> #![feature(inherent_associated_types, non_lifetime_binders, type_alias_impl_trait)] #![allow(incomplete_features)] struct Lexer<T>(T); impl Lexer<i32> { type Cursor = (); } type X = impl for<T> Fn() -> Lexer<T>::Cursor; //~ ERROR associated type `Cursor` not found for `Lexer<T>` in the current scope fn main() {} </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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes
Change:
<ins> // Checks that if the crate name is too long on mobile, it will not grow and overflow its parent // (thanks to text overflow ellipsis). go-to: "file://" + |DOC_PATH| + "/test_docs/index.html" // First we change the title to make it big. set-window-size: (350, 800) // We ensure that the "format" of the title is the same as the one we'll use. assert-text: (".mobile-topbar .location a", "test_docs") // We store the height we know is correct. store-property: (".mobile-topbar .location", {"offsetHeight": height}) // We change the crate name to something longer. set-text: (".mobile-topbar .location a", "cargo_packager_resource_resolver") // And we check that the size remained the same. assert-property: (".mobile-topbar .location", {"offsetHeight": |height|}) // Now we check if it works for the non-crate pages as well. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" // We store the height we know is correct. store-property: (".mobile-topbar .location", {"offsetHeight": height}) set-text: (".mobile-topbar .location a", "Something_incredibly_long_because") // And we check that the size remained the same. assert-property: (".mobile-topbar .location", {"offsetHeight": |height|}) </ins>

Discussion:
On mobile using both firefox and Brave. !
This is presumably a rustdoc issue, unless our css somehow affects it, but I doubt it.
Taking a look.
Change:
for dir in current.ancestors() { let candidate = dir.join("x.py"); if candidate.exists() { <del> let mut cmd = x_command(dir); cmd.args(env::args().skip(1)).current_dir(dir); let result = exec_or_status(&mut cmd); match result { Err(error) => { eprintln!("Failed to invoke `{:?}`: {}", cmd, error); } Ok(status) => { process::exit(status.code().unwrap_or(1)); } </del> <ins> let shell_script_candidate = dir.join("x"); let mut cmd: Command; if shell_script_candidate.exists() { cmd = x_command(dir); cmd.args(env::args().skip(1)).current_dir(dir); } else { // For older checkouts that do not have the x shell script, default to python cmd = Command::new(python()); cmd.arg(&candidate).args(env::args().skip(1)).current_dir(dir); </ins> } <ins> let result = exec_or_status(&mut cmd); handle_result(result, cmd); </ins> } }

Discussion:
Since , src/tools/x unconditionally looks for the shell scripts when running. That's good in most cases because it avoids having to run python. However, on old checkouts the shell scripts don't exist and it needs to fall back to using python. cc do you have time to fix this? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim If it can wait for the weekend to pass, then yes. Anyone, feel free to claim of you can do it in the weekend
i could help! Could you give me some pointers on what needs to be done?
What you should do is re-add the code that was removed in , using it when the shell scripts are not found, but x.py is. You could even add an env var that forces the use of python, but that's a later step.
I see! Okay I'll give this a shot! But I may need more time than just the weekends cause I probably need some time to figure things out. But if it's urgent then feel free to unassign me claim
I don't think this is necessary, there shouldn't be any functionality that's available in python but not shell.
It is future-proofing for when python does get used only when building bootstrap, and the shell scripts won't be able to call python
That can be done with a function argument so it's not exposed to users.
Yes, it can work like this.
Hi ! Currently working on this. Could you list out the steps needed to replicate this issue so I could get a bit more context of the problem? Thank you!
install it from a current version of the repository, then check out any commit from before and run . It will says "x.py not found" even though it exists in the repository.
Err sorry, that was the commit that changes src/tools/x - you want the commit that initially the ./x and x.ps1 scripts.
One reason may be because they work on a pr that started before this commit, and that (miraculously) didn't conflict. Another reason would have been because the work was done on stable/beta, but I think the scripts are now on stable (correct me if I'm wrong)
Change:
}; let mut any_error = false; let mut any_bot = false; <del> let t: ty::t = fcx.infcx().next_ty_var(); </del> for e in args.iter() { <del> check_expr_has_type(fcx, &**e, t); </del> <ins> check(fcx, &**e, t); </ins> let arg_t = fcx.expr_ty(&**e); if ty::type_is_error(arg_t) { any_error = true;

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.