jiebi/CodeConvo huggingface dataset:
Change:
fn main() { let r = { let x = ~42; <del> let f = proc() &x; //~ ERROR: borrowed value does not live long enough </del> <ins> let f = proc() &x; //~ ERROR: `x` does not live long enough </ins> f() };

Discussion:
compiles . Runs . Connection refused and segfault.
This is a bug in the treatment of captured variables. The line in question is: This is moving into the loop repeatedly when you should only be allowed to do it once. I think I've seen this bug before, but just in case, cc
thanks I've seen some reports of bugs like this before -- it's clear that we need to revisit the code used to check "once fns" -- it was as a temporary start towards support (under a -Z flag) and then pressed into full service, clearly not quite ready for prime time.
Nominating.
updated title to reflect the real issue at hand.
cc
Assigning 1.0, max(P-backcompat-lang, P-high). Gotta fix. edit: The use of above is sort of a joke: take the max of the two P-tag inputs. (Also, I originally wrote P-backcompat-libs, but I'm pretty sure that was a typo.)
Change:
#[stable(feature = "rust1", since = "1.0.0")] fn as_slice(&self) -> &[T] { unsafe { <ins> let p = *self.ptr; if cfg!(not(stage0)) { // NOTE remove cfg after next snapshot assume(p != 0 as *mut T); } </ins> mem::transmute(RawSlice { <del> data: *self.ptr, </del> <ins> data: p, </ins> len: self.len }) }

Discussion:
Consider the following benchmark: Which produces the following output: test _range ... bench: ns/iter (+/- 1033) test assembly ... bench: ns/iter (+/- 248) test enumerate ... bench: ns/iter (+/- 566) test iter ... bench: ns/iter (+/- 465) test position ... bench: ns/iter (+/- 384) is the correct abstraction for this but its code is 50% slower than the naive assembly implementation and 40% slower than .
I'm getting different results: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 8183) test enumerate ... bench: ns/iter (+/- 1615) test iter ... bench: ns/iter (+/- 4164) test position ... bench: ns/iter (+/- ) test result: ok. 0 passed; 0 failed; 0 ignored; 4 measured (the assembly version segfaulted on me).
wow. What platform?
On a macbook. Here's another run without a bunch of stuff in the background screwing up the variance: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 2331) test enumerate ... bench: ns/iter (+/- 2851) test iter ... bench: ns/iter (+/- 3995) test position ... bench: ns/iter (+/- 978)
The IL for -s inner loop is (de-gensymmed) Which looks sane, except for the spurious null check (which remains in the assembly). Benchmarks on my machine:
The spurious null check is the issue – writing a over it in the object code gives ±385 ns/iter on my laptop.
New code: New results: Unacceptable performance.
Change:
LL |         return true; |         ++++++     + <del> error: aborting due to 8 previous errors </del> <ins> error: aborting due to 10 previous errors </ins> Some errors have detailed explanations: E0308, E0658. For more information about an error, try `rustc --explain E0308`.

Discussion:
The same warning is produced at other places like statements, expressions, functions etc. For completeness and consistency it should be produced for pattern and expression fields too. No response rustc 1.74.0-nightly ( 2023-09-01) binary: rustc commit-hash: commit-date: 2023-09-01 host: x8664-pc-windows-msvc release: 1.74.0-nightly LLVM version: 17.0.0 rustc version older than 1.74.0 may ICE on this code. The ICE was fixed in 1.74.0 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reason these warnings are not produced is because the lint infrastructure currently exposes no hooks for and , i.e. there are no and methods on (or for that matter). To fix the issue, these methods may have to be here: and then invoked from here: and here: Alternatively, we can emit the warning from the already existing and methods of and not bother with the above changes at all.
Yeah, I would expect this is the best way of doing it.
claim
label -needs-triage
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. // Regression test for HashMap only impl'ing Send/Sync if its contents do use std::collections::HashMap; use std::rc::Rc; fn foo<T: Send>() {} fn main() { foo::<HashMap<Rc<()>, Rc<()>>>(); //~^ ERROR: the trait `core::marker::Send` is not implemented for the type `alloc::rc::Rc<()>` } </ins>

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
use crate::builder::crate_description; use crate::builder::Cargo; <del> use crate::builder::{Builder, Kind, RunConfig, ShouldRun, Step}; </del> <ins> use crate::builder::{Builder, Kind, PathSet, RunConfig, ShouldRun, Step, TaskPath}; </ins> use crate::cache::{Interned, INTERNER}; use crate::config::{LlvmLibunwind, RustcLto, TargetSelection}; use crate::dist;

Discussion:
I tried this code: I expected this to happen: Bootstrap builds cranelift, since I named it explicitly. Instead, this happened: Nothing, since I didn't have cranelift configured in : At a minimum, I would expect this to give an error or warning that I need to configure codegen-backends. It would be even nicer if we could treat as only controlling the defaults, instead of as a hard-off switch, like how works. That should be possible to do by looking at the we're passed. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The first element in codegen-backends is used as default backend. In addition even if the CodegenBackend step were to directly use the passed in paths, assembling the toolchain did still only add the backends in codegen-backends to the sysroot. Having path specifiers for one step affect another step doesn't feel right. For check builds I do agree this is an improvement. Although I personally actually use this behavior to have build all backends, not just cranelift (by enabling all in codegen-backends) It did be nice to have a replacement for this. In addition for at the very least a warning makes sense.
Does it make sense to separate cgclif and cggcc into different steps in that case? cc
That doesn't have any effect on if specifying a backend as path will add it to the sysroot.
Change:
fn bar(foo: Foo) -> u32 { match foo { Foo::B(i) => i, //~ ERROR E0164 <ins> //~| NOTE not a tuple variant or struct </ins> } }

Discussion:
From: src/test/compile- Error E0184 needs a span_label, updating it from: To: Bonus: I'm not sure that note is helping, you can probably just remove it.
On it
- I am releasing this one so someone else can take it, but feel free to come grab another one

From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

From: src/test/compile- Error E0164 needs a span_label, updating it from: To:
Change:
} macro_rules! gate_feature_post { <ins> ($visitor: expr, $feature: ident, $span: expr, $explain: expr, $help: expr) => { gate_feature_fn!($visitor, |x: &Features| x.$feature, $span, sym::$feature, $explain, $help) }; </ins> ($visitor: expr, $feature: ident, $span: expr, $explain: expr) => { gate_feature_fn!($visitor, |x: &Features| x.$feature, $span, sym::$feature, $explain) };

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
let mut crates = String::new(); let mut after = String::new(); <ins> let mut mod_attr_pending = String::new(); </ins> for line in s.lines() { let trimline = line.trim();

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
/// Using [`Acquire`] as success ordering makes the store part of this /// operation [`Relaxed`], and using [`Release`] makes the final successful /// load [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], <del> /// [`Acquire`] or [`Relaxed`] and must be equivalent to or weaker than the /// success ordering. </del> <ins> /// [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on pointers.

Discussion:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-50687-ice-on-borrow.rs:40:17 | LL |     let _: () = Borrow::borrow(&owned); |            --   ^^^^^^^^^^^^^^^^^^^^^^ |            |    | |            |    expected `()`, found reference |            |    help: consider dereferencing the borrow: `*Borrow::borrow(&owned)` |            expected due to this | = note: expected unit type `()` found reference `&_` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
(Non-minimized) Repro case: It can correct fail with E0308 "mismatched types" if that line is removed. <details<summaryCrash log</summary</detailsThe ICE is repro with 1.27-beta and nightly. <details<summaryOn 1.26-stable, this will produce an infinite recursion instead.</summary</detailsMaybe the same as .
This, I think, can be closed: in nightly and 1.36.0 the code no longer produces an ICE and instead fails with an error "just fine".
Do you think you could create a minimal test to close this issue with?
This still needs a more minimal reproduction. I can't get to build using any of the compilers that are problematic. The reproduction should show what is happening from including that causes this issue.
Change:
} <del> // Check for overloaded operators if allowed. </del> <ins> // Check for overloaded operators if not an assignment. </ins> let result_t; <del> if allow_overloaded_operators == AllowOverloadedOperators { </del> <ins> if is_binop_assignment == SimpleBinop { </ins> result_t = check_user_binop(fcx, callee_id, expr,

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:
Change:
} } <ins> fn escape_string(s: &[u8]) -> String { str::from_utf8(s).map(|s| s.to_owned()).unwrap_or_else(|_| { let mut x = "Non-UTF-8 output: ".to_string(); x.extend(s.iter().flat_map(|&b| ascii::escape_default(b)).map(char::from)); x }) } </ins> match prog { Ok(prog) => { <del> fn escape_string(s: &[u8]) -> String { str::from_utf8(s).map(|s| s.to_owned()).unwrap_or_else(|_| { let mut x = "Non-UTF-8 output: ".to_string(); x.extend(s.iter().flat_map(|&b| ascii::escape_default(b)).map(char::from)); x }) } </del> if !prog.status.success() { let mut output = prog.stderr.clone(); output.extend_from_slice(&prog.stdout);

Discussion:
On macOS rustc runs dsymutil to generate debug info files. This invocation incorrectly ignores dsymutil's output and exit status. rustc thus succeeds even if dsymutil fails or crashes. Example: in , dsymutil crashed and left behind a corrupt .dSYM file. rustc nevertheless succeeded, thereby confusing the user after the debugger ignored that bad debug info. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc ignoring :
claim
Change:
// try to add a suggestion in case the field is a nested field of a field of the Adt if let Some((fields, substs)) = self.get_field_candidates(span, &expr_t) { for candidate_field in fields.iter() { <del> if let Some(field_path) = self.check_for_nested_field(span, field, candidate_field, substs, vec![]) { </del> <ins> if let Some(field_path) = self.check_for_nested_field( span, field, candidate_field, substs, vec![], self.tcx.parent_module(id).to_def_id(), ) { </ins> let field_path_str = field_path .iter() .map(|id| id.name.to_ident_string())

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue:
Change:
#![feature(is_some_with)] #![feature(maybe_uninit_slice)] #![feature(maybe_uninit_write_slice)] <del> #![feature(nonnull_slice_from_raw_parts)] </del> #![feature(panic_can_unwind)] #![feature(panic_info_message)] #![feature(panic_internals)]

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
} #[test] <ins> fn test_chars_debug() { let s = "ศไทย中华Việt Nam"; let c = s.chars(); assert_eq!( format!("{:?}", c), r#"Chars(['ศ', 'ไ', 'ท', 'ย', '中', '华', 'V', 'i', 'ệ', 't', ' ', 'N', 'a', 'm'])"# ); } #[test] </ins> fn test_bytesator() { let s = "ศไทย中华Việt Nam"; let v = [

Discussion:
Currently, the Debug of prints the underlying bytes, rather than the chars: Returns: As I was trying to work out what was (whether it was unicode points or bytes or something else), the first output was v confusing - is there a reason we don't print something like the second case? Would you take a PR to change this? I couldn't find any previous discussion on this - was the closest I could find.
The first one is UTF-8 bytes. You see this because the impl for is auto-generated: Strictly speaking, since the bytes inside of should always be valid UTF-8, this could have a custom impl that makes it pretend to contain a string by formatting the member as . The reason it doesn't display as individual chars is because it doesn't have individual ; determining their boundaries is the entire point of the iterator. I suppose this same argument could be used against the call to , which needs to scan the whole string to validate it. (but then the solution seems to be to use , which seems awfully heavy-handed for a impl. And perhaps it doesn't even matter, because the cost of most impls probably outweighs the cost of this validation) I guess that, questionable concerns of efficiency aside, my main concern is simply that showing a list of individual chars would be... dishonest, I guess.
Do & contain more data than ? I had thought they both contained the underlying bytes and then these were decoded as needed - including as part of the & implementations
No, they contain the same data. They're all just UTF-8 bytes. And the implementation of simply writes the bytes contained in the directly to the instance. Suppose we are writing to STDOUT. On UNIX, the impl writes these bytes directly to the underlying file descriptor with no processing: I would imagine this is because the console on any UNIX platform almost certainly uses UTF-8.[^1] It is your terminal application that is then responsible for decoding these bytes and producing glyphs. Considering that UTF-8 dominates much of the web space as well, it's quite possible that even on the playground, these bytes are ultimately sent over the wire to your PC with minimal processing, where your browser is responsible for decoding and displaying them. On Windows, transcodes the UTF-8 into the UTF-16 format expected by the windows APIs: and then Windows does whatever it does with those UTF-16 code units.

(Quite likely, it hands them directly to the console, which is then responsible for decoding and displaying them) [^1]: (I think in actuality UNIX accepts arbitrary strings of bytes, and then the portions of these strings which are valid UTF-8 are rendered appropriately by the console. I don't know; doesn't really matter)
OK, so given that - is there still an objection to displaying the unicode characters for but not ?
Change:
<ins> // Regression test for issue #66898 // Tests that we don't emit a nonsensical error message // when a macro invocation tries to access `self` from a function // that has a 'self' parameter pub struct Foo; macro_rules! call_bar { () => { self.bar(); //~ ERROR expected value } } impl Foo { pub fn foo(&self) { call_bar!(); } pub fn bar(&self) { } } fn main() {} </ins>

Discussion:
Hi, ... returns: () Message says , even though it does have a parameter, which is kinda confusing. This happens only on beta and nightly, since current stable doesn't provide that hint at all. Thanks, Patryk.
This happened to me on an old nightly (I believe 1.38.0 when it was still nightly, I may be wrong)
Running into this issue on latest stable as well. What is the actual problem?
I just ran into what appears to be the same issue on , in the context of a trait method.
Change:
/// This is useful for initializing types which lazily allocate, like /// `Vec::new` does. // FIXME: rename to dangling() to match NonNull? <del> pub fn empty() -> Self { </del> <ins> pub const fn empty() -> Self { </ins> unsafe { <del> let ptr = mem::align_of::<T>() as *mut T; Unique::new_unchecked(ptr) </del> <ins> Unique::new_unchecked(mem::align_of::<T>() as *mut T) </ins> } } }

Discussion:
It should either elaborate on AssertUnwindSafe or else drop the claim that it will elaborate below.