jiebi/CodeConvo huggingface dataset:
Change:
trace_macros, }; <ins> #[stable(feature = "core_primitive", since = "1.43.0")] pub use core::primitive; </ins> // Include a number of private modules that exist solely to provide // the rustdoc documentation for primitive types. Using `include!` // because rustdoc only looks for these modules at the crate level.

Discussion:
I got a bug report on Diesel from someone who has a database column called . This lead to us attempting to generate the following code: which causes a type mismatch because their struct is shadowing the primitive. I'd like to change the generated code to be , which is the path that the rustdoc for libstd indicates it should be, but the type doesn't exist there, or anywhere else I can find. I would assume the same issue exists for , , and all the numeric types.
Since the module already exists, the type cannot be called . But it can be aliased as I guess.
would make sense as well
Related: The reason these primitives are not put into prelude was because but I think this is no longer a problem? (cc
Tagging this as a library issue. The solution (if it happens on our side) is to add a module or (and reexport it from as well) as described in In the meantime Diesel can privately define such a module itself and use it when unintended shadowing can happen. It doesn't make much sense to put primitive types into the std prelude because they are already in a prelude actually, it's just not the std prelude, but an additional language prelude one level below (as it was decided in and ).
I agree that primitives should be exposed at some absolute path. sounds reasonable.
I'd be happy to work on this. What's needed besides the implementation? I'm not entirely sure what a test for this should look like. Just a run-pass test that shadows and references ? Do we need one for every type?
I would start with a PR that has: Implementation, Module-level documentation for std::primitive with a helpful example that communicates why you may want to use this, One run-pass test for a shadowed bool as you suggested.
Sounds good. I'll try to get that PR done this week.
Does this need a feature gate?
Yes I believe so.
Triage: not aware of anything happening here.
Change:
// ignore the inputs to a projection, as they may not appear // in the normalized form if self.just_constrained { <del> if let ty::Projection(..) = t.kind() { </del> <ins> if let ty::Projection(..) | ty::Opaque(..) = t.kind() { </ins> return ControlFlow::CONTINUE; } }

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. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
let mut ty = ty; match ty.kind() { <del> ty::Float(..) | ty::Char | ty::Str | ty::Never | ty::Foreign(..) => {} </del> <ins> ty::Float(..) | ty::Char | ty::Str | ty::Never | ty::Foreign(..) | ty::GeneratorWitness(..) => {} </ins> ty::Bool => { if options.contains(EncodeTyOptions::NORMALIZE_INTEGERS) {

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 --
claim
Change:
pub fn is_trait(self) -> bool { matches!(self, Kind::Trait) } <del> pub fn is_struct_enum_union(self) -> bool { matches!(self, Kind::Struct | Kind::Enum | Kind::Union) </del> <ins> pub fn is_type(self) -> bool { matches!(self, Kind::Struct | Kind::Enum | Kind::Union | Kind::Typedef) </ins> } pub fn from_item(i: &Item) -> Self {

Discussion:
Produces json (abridged) which is correct, but fails for this modify labels: +A-rustdoc-json +A-testsuite +T-rustdoc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This was found while working on , as it causes jsondoclint to fail for core (in addition to it catching the linked issue)
Change:
// revisions: aarch64_wrs_vxworks // [aarch64_wrs_vxworks] compile-flags: --target aarch64-wrs-vxworks // [aarch64_wrs_vxworks] needs-llvm-components: aarch64 <del> // revisions: arm64_32_apple_watchos // [arm64_32_apple_watchos] compile-flags: --target arm64_32-apple-watchos // [arm64_32_apple_watchos] needs-llvm-components: aarch64 // revisions: arm64e_apple_darwin // [arm64e_apple_darwin] compile-flags: --target arm64e-apple-darwin // [arm64e_apple_darwin] needs-llvm-components: aarch64 // revisions: arm64e_apple_ios // [arm64e_apple_ios] compile-flags: --target arm64e-apple-ios // [arm64e_apple_ios] needs-llvm-components: aarch64 </del> // revisions: arm_linux_androideabi // [arm_linux_androideabi] compile-flags: --target arm-linux-androideabi // [arm_linux_androideabi] needs-llvm-components: arm

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.
Change:
#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> SharedChan<T> { fn send(&self, x: T) { shared_chan_send(self, x) } fn try_send(&self, x: T) -> bool { shared_chan_try_send(self, x) }

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
clause.push_str(&format!("{}: {}", ty, GenericBounds(bounds))); } } <del> &clean::WherePredicate::RegionPredicate { ref lifetime, ref bounds } => { clause.push_str(&format!("{}: ", lifetime)); for (i, lifetime) in bounds.iter().enumerate() { if i > 0 { clause.push_str(" + "); } clause.push_str(&lifetime.to_string()); } </del> <ins> &clean::WherePredicate::RegionPredicate { ref lifetime, ref bounds } => { clause.push_str(&format!("{}: {}", lifetime, bounds.iter() .map(|b| b.to_string()) .collect::<Vec<_>>() .join(" + "))); </ins> } &clean::WherePredicate::EqPredicate { ref lhs, ref rhs } => { if f.alternate() {

Discussion:
Example: Behavior is observable on stable and nightly. Clearly can be shortened to just .
This is a problem with how the struct is represented when re-exporting from a different crate. For example, : The gets converted into a where clause in the re-export, but i'm not sure what introduces the duplicate lifetime bound.
Current documentation still has evidence of this bug: see e.g. in
Change:
} } <ins> pub fn is_range_separator(&self) -> bool { [DotDot, DotDotDot, DotDotEq].contains(&self.kind) } </ins> pub fn is_op(&self) -> bool { match self.kind { Eq | Lt | Le | EqEq | Ne | Ge | Gt | AndAnd | OrOr | Not | Tilde | BinOp(_)

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: is a valid expression (a  literal), so this error is misleading. It should at a minimum have a suggestion to replace with the valid version , and probably should just work. It also imho ideally shouldn't be a hard parser error blocking semantic passes; the parse of is fairly unambiguously intended, even if we decide we should still require the parenthesis. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm interested! Where should I look first? (I have no experience in rustc, some general experience in compilers tho)
The is a good place to start. If you have some compiler development experience already, that should get you going quickly enough. One specifically relevant section is is likely to be where you'll need to change. Also, ; you can to assign yourself to the issue to track that you're working on it.
For extra context, is accepted in expression position at least for both , , and obviously , so I have absolutely no idea what makes different that it causes a parser error in this case.
claim
Change:
<ins> fn foo() { oops; //~^ ERROR: cannot find value `oops` in this scope } unsafe fn bar() { std::mem::transmute::<_, *mut _>(1_u8); } fn main() {} </ins>

Discussion:
Found with a <details<summaryBacktrace</summary</details<details<summaryBacktrace</summary</detailsRegression in nightly-2022-05-28, perhaps from () nightly: 2022-11-18 on playground with debug assertions: slightly newer, built locally from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Might be a duplicate of
Should be an easy fix, just need to delay a bug if the transmute source/target has (non-region) infer vars and bail from the fn.
claim
Change:
stack: &TraitObligationStack<'o, 'tcx>, candidate: &SelectionCandidate<'tcx>, ) -> Result<EvaluationResult, OverflowError> { <del> let result = self.evaluation_probe(|this| { </del> <ins> let mut result = self.evaluation_probe(|this| { </ins> let candidate = (*candidate).clone(); match this.confirm_candidate(stack.obligation, candidate) { Ok(selection) => {

Discussion:
Split out from the discussion in See for the original comments. The issue is caused by the way that we handle regions in the evaluation cache. When we insert a result into the evaluation cache (either or , we use a 'freshened' version of the original as the key. The 'freshened' has all non-late-bound regions erased. Unfortunately, this can lead to issues if we try to evaluate the following two predicates: When we evaluate , we'll get , since the region parameter in our trait ref is known to match the impl. We will then cache the result as . If we later try to evaluate , we will end up matching the evaluation cache entry, giving us a result of . However, we should have gotten a result of , since we don't know that holds. This is really difficult to observe in practice, for a number of reasons: The relevant trait predicates need to get evaluated, not just registered in a . Trait evaluation usually goes through the query, which canonicalizes the regions in the input trait ref. To end up trying to evaluate , we need to end up calling on it, with a different original trait ref used in the original query. Using instead of only seems to cause an error when it results in the incremental hash changing (I don't know if it's possible to weaponize this into extending a lifetime). As a result, I haven't been able to minimize this.
With landing, this is going to start causing ICEs (since the query result is actually changing across compilatioon sessions). I'm still not sure if this can actually cause unsoundness, but it should be fixed anyway, since it's a bug in a pretty subtle part of the trait system. cc - I'm not familiar enough with the relevant code to be sure of how to fix this.
This can be reproduced by following the instructions in after lands - it turns out that that reproducer also hits this issue. Unfortunately, that reproducer is quite large, and I'm not sure how to minimize it.
I wouldn't know where to look (or rather, I only know the vague shape of all of this, but not enough details) and would defer to or myself. The only thing I can think of is we should blanket use any time freshening erased a lifetime.
The same issue happens on
managed to create a minimized reproducer in
Change:
None => return Ok(()), }; <ins> // Render the replacements for each suggestion let suggestions = suggestion.splice_lines(&**sm); if suggestions.is_empty() { // Suggestions coming from macros can have malformed spans. This is a heavy handed // approach to avoid ICEs by ignoring the suggestion outright. return Ok(()); } </ins> let mut buffer = StyledBuffer::new(); // Render the suggestion message

Discussion:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.
Change:
/// Check whether peekable iterator is empty or not. #[inline] pub fn is_empty(&mut self) -> bool { <del> self.peek().is_some() </del> <ins> self.peek().is_none() </ins> } }

Discussion:
An iterator returns None if it is empty, but Peekable's isempty is defined like this: This needs to be changed to use isnone(). In fact, the code from testpeekableis_empty() fails. It looks like this escaped detection because of a missing "#[test]"
Whoops! Feel free to submit a pull request fixing it. :)
Change:
self.ch == Some(c) } <del> fn error<T>(&self, reason: ErrorCode) -> Result<T, ParserError> { </del> <ins> fn error<U>(&self, reason: ErrorCode) -> Result<U, ParserError> { </ins> Err(SyntaxError(reason, self.line, self.col)) }

Discussion:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.
Change:
pub const RUSAGE_CHILDREN: c_int = -1; pub const RUSAGE_THREAD: c_int = 1; } <ins> #[cfg(any(target_os = "bitrig", target_os = "openbsd"))] </ins> pub mod posix08 { <ins> use types::os::arch::c95::c_int; pub const O_CLOEXEC: c_int = 0x10000; } #[cfg(target_os = "netbsd")] pub mod posix08 { use types::os::arch::c95::c_int; pub const O_CLOEXEC: c_int = 0x400000; </ins> } pub mod bsd44 { use types::os::arch::c95::c_int;

Discussion:
After lands we will be setting on all file descriptors on unix in the standard library. Currently we do so in a nonatomic fashion, however, so it's possible to continue to leak file descriptors into children if a thread is concurrently forking. Many platforms have methods of creating file descriptors atomically, but many of the APIs are quite new and they need to be properly detected at runtime. For example, the current instances of that need to be migrated are listed below. A reminder of our minimum platform requirements are linux 2.6.18 and OSX 10.7. [x] - this should specify the flag. This flag was in linux 2.6.23 and appears to exist on OSX 10.7. [x] - this should be specify the flag in the argument (second). This flag was only in linux 2.6.27 and does not exist on OSX. [x] - this should be replaced with a call to . This system call was only in linux 2.6.28 and does not exist on OSX. [x] - this should be replaced with (linux 2.6.27, not on OSX) or (linux 2.6.24, appears to exist on OSX 10.7). [x] - this could be replaced with on linux 2.6.27 and perhaps on OSX (not confirmed). The hard part about this bug is figuring out if it's possible to avoid compile-time detection of these functions (and instead rely on runtime detection).
cc
I know this is closed, but I just have to comment on how well thought out and organised the original description was - how clearly the problem is captured and then it's solution tracked. Well done everyone.
Change:
<ins> // issue: 113903 #![feature(return_position_impl_trait_in_trait)] use std::ops::Deref; pub trait Tr { fn w() -> impl Deref<Target = Missing<impl Sized>>; //~^ ERROR cannot find type `Missing` in this scope } impl Tr for () { fn w() -> &'static () { &() } } 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
Regression in nightly-2023-07-11 Regression in cc ^^
This is possibly fixed by , or alternatively . I'll have to look into it, but I'll look into it regardless by tomorrow.
Change:
= help: add `#![feature(function)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'function' <del> --> $DIR/internal-unstable.rs:35:27 </del> <ins> --> $DIR/internal-unstable.rs:36:27 </ins> | LL |     pass_through_noallow!(internal_unstable::unstable()); |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
Discussed in zulip: https://rust- The problem is that compiler doesn't accept code like this: But it accepts code when merging mutiple annotations into one: : Version 1.48.0-nightly ( 2020-09-22) cc which modified some const stability checks. modify labels: E-mentor
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
just refactored a few individual calls to into a single helper function. only looks for the first attribute it seems. Shouldn't be hard to fix.
assign
Error: Parsing assign command in failed: ...'n bugadani' ''... Please let know if you're having trouble with this bot.
The PR did not actually fix the issue. The test case to the PR also works without the PR. A test case that would fail would actually check whether a second attribute would be honored. Adding a second attribute was silently ignored, and it still is after the PR. Edit: nevermind, all is good:
It doesn't hurt to double check, just takes some time :)
Change:
version = "0.1.0" dependencies = [ "colored", <del> "compiletest_rs", </del> "env_logger 0.9.0", "getrandom 0.2.0", <ins> "lazy_static", </ins> "libc", "log", "measureme 9.1.2", "rand 0.8.5", <ins> "regex", </ins> "rustc-workspace-hack", <del> "rustc_version", </del> "shell-escape", "smallvec", <ins> "ui_test", </ins> ] [[package]]

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.
Change:
$crate::ptr::addr_of_mut!(VAL) as *mut $crate::primitive::u8, destroy, ); <del> STATE = 1; </del> <ins> STATE.set(1); </ins> $crate::option::Option::Some(&VAL) } // 1 == the destructor is registered and the value

Discussion:
Miri detects UB when running the following program: With and With
I see the bug. We have (which means fns in std automatically trap aborts) but that doesn't apply to functions which are present in the macro expansion (some of which can't really be moved outside the macro). Ill fix in like an hour or two. We just need to guard panics in a couple places. In practice I think this should not call problems and we'd just hit an abort guard in an defined in a few frames up, although perhaps that's not true in 100% of cases (I can update on this once I implement the fix).
The is that the fix to this may need to be backported thus I am tagging this with P-high.
the fix was merged and a backport was rejected:
Change:
/unicode-downloads /target /src/tools/x/target <del> # Generated by compiletest for incremental /tmp/ </del> # Created by default with `src/ci/docker/run.sh` /obj/

Discussion:
When doing a build with rustbuild, it turns out that two tmp/ dirs end up being created. One is in the directory that rustbuild owns, and one is in the current directory (next to the directory). The one next to the directory contains some information for partitioning tests and information about the error index. Both of these shouldn't exist and their output should be in the rustbuild build/ directory. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
More on rustbuild:
I seem to recall seeing a tmp directory inside build, but I can't seem to recreate it now. Maybe it only appears temporarily during some particular steps and I've deleted it. What do you see as the steps for removing the tmp directory inside build/? Or is the solution to leave that and move the tmp directory created in the root into the build/ directory?
I'd advocate to move the root tmp directory into the build/ directory, personally. The strategy here is to track down what's creating that dir (I'm not sure myself) and just update it to all use the build/ dir
Doesn't seem to be case anymore, creates only .
Perhaps creates it because I still see the second outside of the directory created in the last few days.
claim Indeed created this directory, I'll see if I can fix it.
This directory is created by tests which use like . I'll have PR soon.
cc (re-adds the outer to ).
release-assignment