jiebi/CodeConvo huggingface dataset:
Change:
<ins> fn main() { let x = foo::Foo::default(); if x.len { //~^ ERROR field `len` of struct `Foo` is private println!("foo"); } } mod foo { #[derive(Default)] pub struct Foo { len: String, } impl Foo { pub fn len(&self) -> usize { 42 } } } </ins>

Discussion:
The code below yields two errors: field is private error in if expression because type is instead of This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least. Is this actually an issue? If you don't consider it one, feel free to close this. - - (originally seen )
I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to be a big problem. Parsing x.len as when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of
Hi Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.
I agree, like you mentioned , there are some improvements we could make, but I think the current behaviour is fine.
Change:
"##, <ins> E0704: r##" This error indicates that a incorrect visibility restriction was specified. Example of erroneous code: ```compile_fail,E0704 mod foo { pub(foo) struct Bar { x: i32 } } ``` To make struct `Bar` only visible in module `foo` the `in` keyword should be used: ``` mod foo { pub(in crate::foo) struct Bar { x: i32 } } # fn main() {} ``` For more information see the Rust Reference on [Visibility]. [Visibility]: https://doc.rust-lang.org/reference/visibility-and-privacy.html "##, </ins> E0705: r##" A `#![feature]` attribute was declared for a feature that is stable in the current edition, but not in all editions.

Discussion:
Environment: rustc 1.31.0-nightly ( 2018-10-25) and rustc 1.30.0 ( 2018-10-24) Rustc produces E0704 error code on the following (syntactically wrong) code: But but neither nor is aware of this error
I can pick this up unless you'd want to do it yourself! This will be the first the I am writing docs for errors (unless Undin wants to do it of course). I guess the general structure looks a bit like this?: Short description of the error Example of bad syntax Example of good syntax Or should there be something else I can add?
Unfortunately, at this moment I don't have enough time to fix it myself so I will be glad if you fix it
I will try my best this week! Hopefully I'll be able to create a PR on Wednesday. I'll tag you once it's done :)
Change:
<ins> error: missing type for `const` item --> $DIR/issue-89574.rs:2:11 | LL |     const EMPTY_ARRAY = []; |           ^^^^^^^^^^^ help: provide a type for the item: `EMPTY_ARRAY: <type>` error: aborting due to previous error </ins>

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
} 0 => {} _ => { <del> if pollfd.revents & libc::POLLOUT == 0 { if let Some(e) = self.take_error()? { return Err(e); } </del> <ins> // linux returns POLLOUT|POLLERR|POLLHUP for refused connections (!), so look // for POLLHUP rather than read readiness if pollfd.revents & libc::POLLHUP != 0 { let e = self.take_error()? .unwrap_or_else(|| { io::Error::new(io::ErrorKind::Other, "no error set after POLLHUP") }); return Err(e); </ins> } return Ok(()); } }

Discussion:
This program succeeds on Linux, even though it shouldn't (assuming you don't have a listener on 1234). Trying to do anything with the socket produces .
Interestingly it does behave as expected on macOS.
Works under WSL as well. Native linux it fails spectacularly.
From an strace, it looks like Linux sets all of , , and at once. We treat as success, but it seems like we should be checking for instead:
Fix here:
Change:
<del> Subproject commit aae04170ccbfeea620502106b581c3c216cd132a </del> <ins> Subproject commit 2dba541881fb8e35246d653bbe2e7c7088777a4a </ins>

Discussion:
broke iOS build. It happened because a new branch was started over instead of . While the new branch has all the required features, they are disabled because script is bundled. So either should be removed completely and constructed by during build process as usually or it should be regenerated and checked in on the every update. The latter perhaps requires a guide for contributors so they to be aware of the issue.
cc
What precisely is broken? Can iOS just not build? Why? Also, what do you mean by the May 8 and June 5 dates? We currently don't have a dependence on autotools, and there are certainly many of us that'd like to keep it that way! Do we just need to check in a new script?
fails to build as old script from doesn't contain support for iOS. Sorry for not being clear enough, those are names of snapshot branches Yep, that should be enough
If you'd like, it's ok to disable jemalloc by default for ios (for rust). Otherwise this is why we prefer to upstream changes before including them in our own repos (for example ).
The fun thing is that actually changes are upstreamed in . But upstream doesn't contain , this file is presented only in Rust repo and therefore it is fragile on updates - rebase on wrong branch and it may be invalid, this very case.
Aha! Well in that case, feel free to submit an updated configure script!
Will do. My point for creating this issue is increasing awareness of problem for future updates
I regenerated the script with autoconf when I made that branch and it does contain the case in the case statement.
Guys, I terribly sorry and apologize, but it is my fault in the end - it seems that iOS was deleted from upstream, from file which caused invalid file to be generated. Looks like a mistake as iOS was deleted in commit related to OpenRISC cleanup. I've sent a new PR to and will update once it lands. Apologies again.
Change:
<ins> error: expected `;`, found `#` --> $DIR/properly-recover-from-trailing-outer-attribute-in-body.rs:4:47 | LL |     #[cfg(feature = )] |     ------------------ only `;` terminated statements or tail expressions are allowed after this attribute LL |     [1, 2, 3].iter().map().collect::<String>() |                                               ^ expected `;` here LL |     #[attr] |     - unexpected token | help: add `;` here | LL |     [1, 2, 3].iter().map().collect::<String>(); |                                               + help: alternatively, consider surrounding the expression with a block | LL |     { [1, 2, 3].iter().map().collect::<String>() } |     +                                            + error: expected statement after outer attribute --> $DIR/properly-recover-from-trailing-outer-attribute-in-body.rs:5:5 | LL |     #[attr] |     ^^^^^^^ error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: the following error was constructed but not emitted', 'error: internal compiler error: the following error was constructed but not emitted' File: --snippet: Version information but still crashes with ` 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: --
Reduced further: searched nightlies: from nightly-2023-11-17 to nightly-2023-12-02 regressed nightly: nightly-2023-11-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </detailsLooks like
This might be a duplicate of , now that I've taken another look at it
When I checked, was already fixed but this one wasn't
You're right-- doesn't reproduce with the latest nightly, but this one does, which I find strange since I thought they have the same root cause, which should address. (Hence also why I closed --it almost exactly duplicated the work in .)
Can be further reduced to

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: the following error was constructed but not emitted', 'error: internal compiler error: the following error was constructed but not emitted' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Regression in nightly-2023-11-21 ping
I found that the code snippet does not cause ICE anymore. Meta: Output:
Change:
let stability_index = time(time_passes, "stability index", (), |_| stability::Index::build(krate)); <ins> time(time_passes, "static item recursion checking", (), |_| middle::check_static_recursion::check_crate(&sess, krate, &def_map, &ast_map)); </ins> let ty_cx = ty::mk_ctxt(sess, type_arena, def_map,

Discussion:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.
Change:
return nullptr; } <del> TargetOptions Options; </del> <ins> TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags(Trip); </ins> Options.FloatABIType = FloatABI::Default; if (UseSoftFloat) {

Discussion:
Please see this StackOverflow <a href=""question</a.
Interesting: rustc -C llvm-args='--list' gives the option list for LLC you might expect llvm-args would be passed to clang (which has the options described in the stack overflow page), and indeed to which these arguments were formerly passed. edit: but it also doesn't seem to be the case recently, as both stable and nightly seem to pass args to llc, not clang.
I think this may actually be a real thing. See . It throws the error: But llc definitely takes this argument. I've traced the argument parsing to . And now that I try it, doesn't seem to work for me either. I'm running . Btw, I ran into this trying to work around .
Added code to print the argv passed to . It prints the args from . So I guess the problem is that llc args != whatever arguments that function expects.
Yes, that appears to be the case. The arguments recognized by and the arguments recognized by the API are different. The Rust compiler uses the LLVM API, so it doesn't recognize certain LLVM options even though they may be valid for . Consider the following: Compile with and execute with . It will print the following: Compare that with the output for (an exercise left to the reader). I need the and for my target, as . I don't know what the solution is here. Is it something for LLVM to solve, or something for rustc to solve?
I'm leaving this open because it's not clear to me how a user should pass arguments directly to llc if they want to; perhaps that's not possible or even something we want. Could you comment on whether we think it's a good idea to allow passing arguments into llc directly? Do we run llc at all? If we don't then it seems that this is not a bug.
Nominating to decide whether we want to expose llc or not (and if we can -- I don't know that we run it directly today). If not, we should close.
I'm moving this to T-dev-tools; it seems like they've put some energy into how to think about the stability of well.
cc this seems like something that would be a tooling/platform team issue if that team existed.

Briefly discussed at the dev-tools meeting: verdict was that this did not seem urgent to address.
Related
Leaving this here in case it's helpful to anyone who comes across this issue: I was able to get what appears to be the full list of the arguments LLVM will accept by way of with: Caution: sharp edges abound.
Exposing these flags would be a matter of using , if we really want to.
Change:
<ins> // This checks that function pointer signatures that are referenced mutably // but contain a &mut T parameter still fail in a constant context: see issue #114994. // // check-fail const fn use_mut_const_fn(_f: &mut fn(&mut String)) { //~ ERROR mutable references are not allowed in constant functions () } const fn use_mut_const_tuple_fn(_f: (fn(), &mut u32)) { //~ ERROR mutable references are not allowed in constant functions } fn main() {} </ins>

Discussion:
Proposing to extract this from . The following examples shouldn't error: While this has been considered part of for a while, it's also been acknowledged as a bug and suggested by to address separately ahead of stabilizing . Indeed it's surprising for users that this would count as handling a mutable reference in const contexts. See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc Fixing this requires changing to skip traversing things inside function pointers. I'm not sure what the best way to achieve that is.
claim
Is there any reason returning a function trait object (e.g. , , etc.) does not work? It works with the feature, but IMO it should have been pulled out like the function pointers. For example this does not compile:
We didn't exhaustively look through all cases that we can exempt here. Anyway, is on the , so this question will be moot soon. :)
Change:
<ins> // Copyright 2014 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. // This test verifies that temporaries created for `while`'s // and `if` conditions are correctly cleaned up. struct Temporary; static mut DROPPED: int = 0; impl Drop for Temporary { fn drop(&mut self) { unsafe { DROPPED += 1; } } } impl Temporary { fn do(&self) -> bool {true} } fn borrow() -> ~Temporary { ~Temporary } pub fn main() { let mut i = 0; // This loop's condition // should call `Temporary`'s // `drop` 6 times. while borrow().do() { i += 1; if i > 5 { break; } } // This if condition should // call it 1 time if borrow().do() { unsafe { assert_eq!(DROPPED, 7) } } } </ins>

Discussion:
I think that and conditions should free any temporaries that occur within them (for conditions it's mandatory, actually, since the condition is evaluated many times). That is, if I write: the temporary returned by should be freed once the condition is evaluated, before entering the body of the . The same holds for . What makes these expressions different from other compound forms is that the conditions are evaluated to scalar booleans, and hence can never create lasting aliases that might need to be preserved. In the case of a while, this is needed because temporaries can never outlive conditional or repeated scopes, and the condition of a while is a repeated scope.
cc
Marking as mentor with myself. This is a fairly small change (if you know what to change :)
I'll work on it :)
0 blocker, P-backcompat-lang.
The fix in was partial, with an is still broken:
Nominated. Seems clear to me that this is a bug we should fix -- the main question is whether to be concerned about backwards compatibility, and -- if so -- what to do about it. I think this is mostly a question for team to decide, but I tagged this issue with T-Lang too in case members want to weight in on whether the behavior is indeed a bug. But it seems clear that having and behave differently is bogus.
Consensus in the compiler team meeting was that we should just fix this and add the resulting PR to the release notes. triage: P-medium
Change:
CTEST_DEPS_bench_$(1)-T-$(2)-H-$(3) = $$(BENCH_TESTS) CTEST_DEPS_perf_$(1)-T-$(2)-H-$(3) = $$(PERF_TESTS) CTEST_DEPS_debuginfo-gdb_$(1)-T-$(2)-H-$(3) = $$(DEBUGINFO_GDB_TESTS) <del> CTEST_DEPS_debuginfo-lldb_$(1)-T-$(2)-H-$(3) = $$(DEBUGINFO_LLDB_TESTS) </del> <ins> CTEST_DEPS_debuginfo-lldb_$(1)-T-$(2)-H-$(3) = $$(DEBUGINFO_LLDB_TESTS)  $(S)src/etc/lldb_batchmode.py  $(S)src/etc/lldb_rust_formatters.py </ins> CTEST_DEPS_codegen_$(1)-T-$(2)-H-$(3) = $$(CODEGEN_TESTS) endef

Discussion:
From time to time the LLDB test suite hangs on the build bots, which leads to the whole pipeline being blocked for an hour. One way to make this problem a bit less severe is to add a time-out to the LLDB test runner which just kills tests that take longer than a few seconds. This should at least reduce the time until the tests can be restarted. cc
cc
Change:
const DEFAULT: bool = false; fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { <del> run.path("compiler/rustc") </del> <ins> run.never() </ins> } fn make_run(run: RunConfig<'_>) {

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've lost so much of my life to this. It looks like the critical missing line is . I would expect this to happen whenever I pass .
The part of emitting is , which is called by . The bit emitting 'Copy ...' is . Notably, does not_ call .
This does not fix the issue and I'm not sure why:
It looks like bootstrap mistakenly thinks that the compiler has been linked and is cached.
So this is still a bug, but it turns out it wouldn't do what I want anyway because it doesn't build . So it would only be able to build crates with (basically nothing).
Yeah you want something like build --stage 1 src/libcore (though we don't support separate crate builds currently, but we could). I think it's not possible today to get bootstrap to copy the compiler but not build anything with it - the compiler itself isn't considered an artifact in some sense.
Right, this issue is asking that to change. I think this would still be useful for what I'm doing now which is only printing the AST and not even doing name resolution ().
Once this is fixed, the docs for in rustc-dev-guide () should be moved to .
Change:
println!("cargo:rerun-if-changed=build.rs"); let target = env::var("TARGET").expect("TARGET was not set"); <del> if cfg!(feature = "system-llvm-libunwind") { </del> <ins> if cfg!(target_os = "linux") && cfg!(feature = "system-llvm-libunwind") { // linking for Linux is handled in lib.rs </ins> return; }

Discussion:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.
Change:
<ins> //@ run-pass #![warn(unused_parens)] #![allow(dead_code)] trait Foo { fn bar(); fn tar(); } macro_rules! unused_parens { ($ty:ident) => { impl<$ty: Foo> Foo for ($ty,) { fn bar() { <$ty>::bar() } fn tar() {} } }; ($ty:ident $(, $rest:ident)*) => { impl<$ty: Foo, $($rest: Foo),*> Foo for ($ty, $($rest),*) { fn bar() { <$ty>::bar(); <($($rest),*)>::bar() //~WARN unnecessary parentheses around type } fn tar() { let (_t) = 1; //~WARN unnecessary parentheses around pattern //~| WARN unnecessary parentheses around pattern let (_t1,) = (1,); let (_t2, _t3) = (1, 2); } } unused_parens!($($rest),*); } } unused_parens!(T1, T2, T3); fn main() {} </ins>

Discussion:
This code: Creates this diagnostic: I ran (note that I created a local project called playground) which created this output: This told me to create an issue here. Going into more depth regarding the issue - the macro expands after one step like so: and we can see where the issue is: These parentheses are indeed fully removable, and it points to an issue in the macro definition. By changing to the compiler no longer emits the warning, because now it expands to which is properly recognized as a tuple with one element, rather than a type surrounded by redundant parentheses. Another way to fix it is to remove the outer parentheses in the macro call: which does compile without warnings, but breaks usage of the macro with tuples with more than two elements: as while its fine to remove the parentheses when there is only one element between the angle brackets ( to ), it is not fine when there are more than one element in the tuple ( to ). Importantly, the compiler still emits the unused parentheses warning and suggests their removal when the macro is called with three types when you haven't removed the parentheses (). Therefore, part of the issue is that rustc detects the problem, and assumes it can fix it by going straight to the macro and correcting it, neglecting previous expansions of the macro which require the currently redundant parentheses. I say part of the issue, because going back to the original diagnostic: rustc marks and as removable, and it suggests you do so: when the diagnostic should really only be suggesting the removal of the outer brackets. I'm not too sure why this one happens. Using Syn's terminology, my best guess is that it has something to do with the span of the outer parentheses including the inner and after expansion. : Also tried with nightly (had identical results):
Change:
<ins> // issue: 113981 pub fn main() {} </ins>

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .