jiebi/CodeConvo huggingface dataset:
Change:
#[unstable(feature = "slice_index_methods", issue = "none")] fn get_mut(self, slice: &mut T) -> Option<&mut Self::Output>; <del> /// Returns a shared reference to the output at this location, without </del> <ins> /// Returns a pointer to the output at this location, without </ins> /// performing any bounds checking. /// Calling this method with an out-of-bounds index or a dangling `slice` pointer <del> /// is *[undefined behavior]* even if the resulting reference is not used. </del> <ins> /// is *[undefined behavior]* even if the resulting pointer is not used. </ins> /// /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html #[unstable(feature = "slice_index_methods", issue = "none")] unsafe fn get_unchecked(self, slice: *const T) -> *const Self::Output; <del> /// Returns a mutable reference to the output at this location, without </del> <ins> /// Returns a mutable pointer to the output at this location, without </ins> /// performing any bounds checking. /// Calling this method with an out-of-bounds index or a dangling `slice` pointer <del> /// is *[undefined behavior]* even if the resulting reference is not used. </del> <ins> /// is *[undefined behavior]* even if the resulting pointer is not used. </ins> /// /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html #[unstable(feature = "slice_index_methods", issue = "none")]

Discussion:
The documentation for these methods state respectively: However these clearly return pointers rather than references. Later on they state the following restrictions, which make sense for references but it isn't clear to me that this restriction is necessary for pointers. At the very least the change needs to be made there too.
These are nightly-only traits that aren't particularly on-track for stabilization anytime soon, but yes, changing them to be correct on those counts would be fine.
Indeed, while it's nightly only I wasn't actually going to call it from nightly, but was looking because of it's use in other stable functions, e.g. . Would make a patch, but I wasn't sure whether to leave the undefined behavior line in or whether it should be removed.
It's still UB, yeah! This is partly because it still has to fulfill the safety conditions of . Obviously, that isn't a full justification: there is the question of adding until the pointer is offset to the "last element", which would not trigger "language UB" via that implementation detail... But the library defines it as UB, which means the implementation may include code that would cause an optimizer to see that it is "impossible" for the defined-UB result to happen. And the question of whether the "surface functions" have this obligation was settled in so yes, the same conclusion applies.
Change:
m1.insert_metric("in-both-want-upwards-and-improved", 1000.0, -10.0); m2.insert_metric("in-both-want-upwards-and-improved", 2000.0, -10.0); } <ins> #[test] pub fn test_bench_once_no_iter() { fn f(_: &mut Bencher) {} bench::run_once(f); } #[test] pub fn test_bench_once_iter() { fn f(b: &mut Bencher) { b.iter(|| { }) } bench::run_once(f); } #[test] pub fn test_bench_no_iter() { fn f(_: &mut Bencher) {} bench::benchmark(f); } #[test] pub fn test_bench_iter() { fn f(b: &mut Bencher) { b.iter(|| { }) } bench::benchmark(f); } </ins> }

Discussion:
functions are run multiple times. Some benchmark functions might depend on some runtime initialisation which may fail. For example: Will print “Benchmarks on even hours are forbidden!” a lot of times. If one opts to not report set-up failure, the benchmark function just keeps processor hot for a while without actually benchmarking anything (and reporting 0ns/iter anyway). Would it be sensible to (one of possible solutions): Not run the same function multiple times, since iteration is done by ; Not run the same again if is not called at least once; Provide a method on to cancel all subsequent runs of the function? Or maybe my approach is incorrect?
If one tries to keep benchmarks in separate files and opts for to cancel further runs of the function, the panic will abort the whole benchmark process (i.e. including the benchmarks in other executables).
For , we want to run on the CI infrastructure to ensure all the tests build. However, we don't want to actually benchmark on the CI infrastructure, because the CI infrastructure isn't reliable enough for benchmarking. Thus, doing more than one iteration on the CI infrastructure just wastes time. And, that time, in particular the wall time, negatively affects my other repos, because generally CI services like Travis CI and Appveyor only allow one project to build at a time, for their free open source tiers. Further, even out side of CI infrastructure, we want contributors to run the benchmarks before sending PRs. But, it's not reasonable to expect them to wait through many minutes of perf tests before asking for a PR. Here are two ideas: a that overrides the default targeted benchmark execution time so that we can write to run tests once. a so we can write . I prefer because that also might help with
Never mind. I just learned that will do exactly what I want: run the benchmarks once each.
This was bugging me, so I implemented the first proposed option: As this is my first real rust code, I imagine its pretty bad quality. A fist attempt is here: I'll clean it up a bit, give it some more testing, then send in a pull request unless anyone offers any opinions before I get that far.
Does anyone have an example on how to use this feature ? I'd like to run a benchmark only once.
:frowning_face:
Change:
self.borrow(assignee_place, diag_expr_id, ty::BorrowKind::MutBorrow); } } <del> /// Truncate projections so that following rules are obeyed by the captured `place`: </del> <ins> /// Truncate `place` so that an `unsafe` block isn't required to capture it. </ins> /// - No projections are applied to raw pointers, since these require unsafe blocks. We capture ///   them completely. <del> /// - No Index projections are captured, since arrays are captured completely. fn restrict_capture_precision<'tcx>(mut place: Place<'tcx>) -> Place<'tcx> { </del> <ins> /// - No projections are applied on top of Union ADTs, since these require unsafe blocks. fn restrict_precision_for_unsafe(mut place: Place<'tcx>) -> Place<'tcx> { </ins> if place.projections.is_empty() { // Nothing to do here return place;

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no error Instead, this happened: rustc 1.55.0-nightly 2018 edition rustc 1.55.0-nightly 2021 edition <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
use rustc::mir::*; use rustc::mir::transform::{MirSuite, MirPassIndex, MirSource}; use rustc::ty::TyCtxt; <ins> use rustc::ty::item_path; </ins> use rustc_data_structures::fx::FxHashMap; use rustc_data_structures::indexed_vec::{Idx}; use std::fmt::Display;

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
<ins> // run-rustfix // edition:2018 // Regression test for issue 79694 fn main() { let _ = async move { }; //~ ERROR 7:13: 7:23: the order of `move` and `async` is incorrect } </ins>

Discussion:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim
Change:
); let variant = adt_def.non_enum_variant(); <del> let fields = c.to_valtree().unwrap_branch(); </del> <ins> let fields = match c.try_to_valtree() { Some(ValTree::Branch(branch)) => branch, _ => { return Some(Self { alignment: true, lifetimes: true, safety: true, validity: true, }); } }; </ins> let get_field = |name| { let (field_idx, _) = variant

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 --
It's coming from calling at this line: I can take a look at it later, doesn't seem to be related to recent changes. Nice find. We're mistakenly assuming that the const has always already been evaluated by the time is called. claim
This one also seems to be regressing in :thinking: cc
Change:
cast_ty: Ty<'tcx>, cast_span: Span, span: Span, <ins> /// whether the cast is made in a const context or not. pub constness: hir::Constness, </ins> } /// The kind of pointer and associated metadata (thin, length or vtable) - we

Discussion:
Compiles in stable rust (1.64) as well as in beta. But in nightly, we get this compilation error: playground link: 64, and beta current nightly
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-24 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems like closures pick the constness of their parent when they should always be notconst
Change:
pub use self::AnnNode::*; use abi; <del> use ast::{FnUnboxedClosureKind, FnMutUnboxedClosureKind}; </del> <ins> use ast::{mod, FnUnboxedClosureKind, FnMutUnboxedClosureKind}; </ins> use ast::{FnOnceUnboxedClosureKind}; use ast::{MethodImplItem, RegionTyParamBound, TraitTyParamBound}; use ast::{RequiredMethod, ProvidedMethod, TypeImplItem, TypeTraitItem}; use ast::{UnboxedClosureKind}; <del> use ast; </del> use ast_util; use owned_slice::OwnedSlice; use attr::{AttrMetaMethods, AttributeMethods}; <del> use codemap::{CodeMap, BytePos}; use codemap; </del> <ins> use codemap::{mod, CodeMap, BytePos}; </ins> use diagnostic; <del> use parse::token::{BinOpToken, Token}; use parse::token; </del> <ins> use parse::token::{mod, BinOpToken, Token}; </ins> use parse::lexer::comments; use parse; <del> use print::pp::{break_offset, word, space, zerobreak, hardbreak}; </del> <ins> use print::pp::{mod, break_offset, word, space, zerobreak, hardbreak}; </ins> use print::pp::{Breaks, Consistent, Inconsistent, eof}; <del> use print::pp; </del> use ptr::P; <del> use std::ascii; use std::io::IoResult; use std::io; use std::mem; </del> <ins> use std::{ascii, mem}; use std::io::{mod, IoResult}; </ins> pub enum AnnNode<'a> { NodeIdent(&'a ast::Ident),

Discussion:
The pretty printer is removing trailing commas from match arms that contain an block expression: Running it with produces: Which when compiled errors with:
Actually, I'm not sure what the right tag is here...
Change:
use prelude::v1::*; <del> use str::FromStr; </del> <ins> use error::Error; use fmt; </ins> use net::{IpAddr, Ipv4Addr, Ipv6Addr, SocketAddr, SocketAddrV4, SocketAddrV6}; <ins> use str::FromStr; </ins> struct Parser<'a> { // parsing as ASCII, so can use byte array

Discussion:
I was writing a generic argument parse validator for my program, which involved matching errors from FromStr::parse. After constraining the error type to Error, I ran into an issue when creating a validator for parsing IP addresses:
Fixed in
Change:
<ins> //@ compile-flags: -C strip=symbols //@ only-msvc //@ run-pass use std::path::Path; pub fn is_related_pdb<P: AsRef<Path>>(path: &P, exe: &P) -> bool { let (exe, path) = (exe.as_ref(), path.as_ref()); path.extension() .map(|x| x.to_ascii_lowercase()) .is_some_and(|x| x == "pdb") && path.file_stem() == exe.file_stem() } pub fn main() { let curr_exe = std::env::current_exe().unwrap(); let curr_dir = curr_exe.parent().unwrap(); let entries = std::fs::read_dir(curr_dir).unwrap(); assert!(entries .map_while(|x| x.ok()) .find(|x| is_related_pdb(&x.path(), &curr_exe)) .is_some()); } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Setting up a release profile with stripped binaries and split debuginfo is made very complicated due to subtle differences in how , and interact with eachother across platforms. In particular, in the following setup: Then when targetting linux/macos, a / debug information file will be generated, while when targeting windows, no debug information file can be found. In particular, no file is created. This seems to stem from how the flags propagate to linker invocation: On windows, of rustccodegenssa only takes into account when choosing how to generate the debug information. If it's set to any value other than None, it will not generate any debuginfo whatsoever, regardless of the value of . On macos/linux, it's  that's responsible both for splitting debuginfo and stripping. A / file will be created only if is set to a value other than 0, and is set to packed. Stripping is, crucially, not a part of the equation. I believe the behavior with the windows should be adjusted to match what is done on macos/linux. In particular, if is set to and strip is set to , then a file should be generated. <!-- 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. --:
I believe is also effected by such inconsistencies. Would be nice to have consistent behavior. And possibly a flag that produces both an unstripped and stripped binary, though that's a separate feature.
Change:
use tvec; use value::Value; <del> use super::MirContext; </del> <ins> use super::{MirContext, LocalRef}; </ins> use super::constant::const_scalar_checked_binop; use super::operand::{OperandRef, OperandValue}; use super::lvalue::LvalueRef;

Discussion:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .
Change:
<ins> // Copyright 2015 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. // Issue #14660 mod bleh { macro_rules! foo { () => { pub fn bar() { } } } foo!(); } fn main() { bleh::bar(); } </ins>

Discussion:
Hey, I have an issue on my macros use. The source code of my macro is . I can't put the pub keyword and if I call my macro like this : The methods aren't public. Am I doing something wrong or is it a compiler's bug ? Thanks in advance.
Any news on it ?
Related?
I think.
I just encountered this. I can reproduce it with:
Now let's just hope it'll be fixed sooner or later !
Hm, what should actually mean? A macro in item position can expand to zero or more items. Should the qualifier apply to all of them, or should it be an error to use it with a multi-item macro? We might want to forbid in this position for 1.0, and come back to the issue later. I had a design for that I think would be rather nice. The current workaround is to write The precise syntax is up to the macro author and can accommodate multiple items. This workaround would be less annoying if we had a "0 or 1" repeat operator in macros.
Could you be a little more explicit about the workaround - I can't seem to get it to work.
from the compiler itself. looks better, with less duplicated code.
Thanks for the examples. If I understand them correctly (neither of which generate forms, iiuc), I should be matching on and inserting a literal in the expansion, but does not seem to work :
It works for me on rustc 1.0.0-dev ( 2015-02-16). The playpen is just to have my fix for .
Thanks for the confirmation. I'll be looking forward to a new nightly for once :)
Change:
// a lock any more because the parent won't do anything and the child is // in its own process. let result = unsafe { <del> let _env_lock = sys::os::env_read_lock(); </del> <ins> let _env_lock = sys::os::env_lock(); </ins> cvt(libc::fork())? };

Discussion:
For example: i686-gnu, i686-gnu, i686-gnu-nopt, i686-gnu-nopt, i686-gnu, i686-gnu-nopt, i686-gnu, i686-gnu-nopt i686-gnu, i686-gnu, i686-gnu, x8664-gnu-distcheck, i686-gnu-nopt, x8664-gnu-tools, i686-gnu, i686-gnu-nopt, i686-gnu-nopt,
Posted a fix at .
Change:
<ins> // check-pass fn func(0u8..=255: u8) {} </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. --code is from <!-- 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
label -T-compiler +T-rustdoc
The playground's nightly compiler doesn't ICE on this example. Are you able to confirm this with the latest nightly?
rustdoc is crashing, not the compiler itself. Playground doesn't have a button for running rustdoc.
MCVE: Marking as P-medium since this happens on valid code.

<!-- 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. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:
Change:
data_layout: "e-m:e-p:64:64-i64:64-i128:128-n64-S128".into(), arch: "loongarch64".into(), options: TargetOptions { <del> code_model: Some(CodeModel::Medium), </del> cpu: "generic".into(), features: "+f,+d".into(), llvm_abiname: "lp64d".into(),

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: outputs version info Instead, this happened: dead loop in entry function. <!-- 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. --:
label O-loongarch
That would be due to the LLVM 18 upgrade.
Yeah. It seems that the CI loongarch64-unknown-linux-gnu ld does not handle relocations correctly.
There is no version of crosstool-ng that supports , I'll revert the until the issue is resolved.
Oooops. Is this communicated with crosstool-ng maintainers?
But maybe crosstool-ng maintainers can't act as well due to the incompatibility between GCC 13.2 and Binutils 2.42 (loongson-community/discussions) :(. I'm not sure how to fix such an incompatibility...
Not yet. binutils 2.42 in progress:
is merged recently that bumped the LoongArch binutils to 2.42, so can we try again?
Yes, with merged, we can retry .
Today's nightly is built off of , which contains and does work: And the code model is indeed in use: So this issue is finally resolved. Thanks for everyone involved!