jiebi/CodeConvo huggingface dataset:
Change:
#[inline] pub fn variant_range(&self) -> Range<VariantIdx> { <del> (VariantIdx::new(0)..VariantIdx::new(self.variants.len())) </del> <ins> VariantIdx::new(0)..VariantIdx::new(self.variants.len()) </ins> } /// Computes the discriminant value used by a specific variant.

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
use std::borrow::Cow::{Borrowed, Owned}; <del> use std::ffi::{c_char, CStr}; </del> <ins> use std::ffi::CStr; use std::os::raw::c_char; </ins> #[test] fn to_str() {

Discussion:
https://crater- https://crater- https://crater- https://crater- Introduced by , most likely, cc
One reasonable fix is to stabilize these types in . That will allow using reexports instead of type aliases, which will remove the ambiguities. They are the same types as stable types in just exposed from a different (but also stable) location in the same crate. (That said, glob vs glob is an acceptable breakage according to the library policy.)
That would be a fast stabilization, but given that they're rather simple types, that seems potentially reasonable.
If we were to stabilize, presumably we'd do that on master and back out the PR from beta? I am reluctant to backport a stabilization to fix this (particularly a fast one, as you mention).
Yeah, reverting the PR on beta seems fine for now.
Change:
// ignore-tidy-linelength <ins> #![feature(doc_cfg)] </ins> pub mod module { pub mod sub_module { pub mod sub_sub_module {

Discussion:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.
Change:
while let Some(item) = panictry!(self.parser.borrow_mut().parse_item()) { ret.push(item); } <del> self.ensure_complete_parse(false); </del> <ins> self.ensure_complete_parse(false, "item"); </ins> Some(ret) }

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
LL | values!(STRING(1) as (String) => cfg(test),); | -------------------------------------------- in this macro invocation | <ins> = help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` </ins> = note: this error originates in the macro `values` (in Nightly builds, run with -Z macro-backtrace for more info) error: macro expansion ignores token `(String)` and any following

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. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "62b467343b94ba476dcb2500d242dadbb39557df889310ac77c5d99100aaac33" dependencies = [ <del> "libc 0.2.112", </del> <ins> "libc", </ins> ] [[package]]

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
} } <del> fn assign_qualif_direct(&mut self, place: &mir::Place<'tcx>, value: bool) { </del> <ins> fn assign_qualif_direct(&mut self, place: &mir::Place<'tcx>, mut value: bool) { </ins> debug_assert!(!place.is_indirect()); <ins> if !value { for (base, _elem) in place.iter_projections() { let base_ty = base.ty(self.ccx.body, self.ccx.tcx); if base_ty.ty.is_union() && Q::in_any_value_of_ty(self.ccx, base_ty.ty) { value = true; break; } } } </ins> match (value, place.as_ref()) { (true, mir::PlaceRef { local, .. }) => { self.qualifs_per_local.insert(local);

Discussion:
For example, after laundering interior mutability through a union, a resulting constant undergoes promotion: label +A-const-eval +F-untagged_unions
Yea, unions should not be "more powerful" than a plain transmute imo. cc
I assume with transmute one can also produce a similar example as the OP? So in which sense are unions more powerful than transmute, Why does this example behave any different than the following?
The union local initially starts without interior mutability qualif. This persist after the first assignment, since u32 does not have interior mutability The move from the cell variant is qualified based on the qualification of the local, so the overall constant is consider not to have interior mutability. The use of the constant in the main function is promoted and fails dynamic checks.
I totally forgot promotion of looks into the definition of ... that'll continue to haunt us for a while I think. :/ Yeah, the analysis clearly is wrong for reading from union fields. But even for values like , I have no idea what the wider consequences are (given that the type is considered interior mutable).
The example can be also modified by moving union access to the runtime code, in which case it will compile successfully, with promoted being placed in .rodata section: In the context of static analysis, I think it would make sense to use strictly type based analysis for unions, in which case the first assignment to a union local would already qualify the local as having interior mutability.
But also, there's supposed to be a 2nd line of defense in our interning code that is somehow failing.
Turns out interning relies in validity checking for this: The example in the OP was caught by validity, so that is good. But the 2nd example was not caught, because we never actually hit an UnsafeCell -- we stop at the union boundary. So maybe the union part of the visitor should also have the kind of ?
do we have an established approach to testing that this second line of defense works? Carefully crafted constant with undefined behaviour might do its job in this case (not sure yet), but maybe we have better alternatives?
We have -Zunleash-the-miri-inside-of-you but that only helps for checks, not for promoted restrictions... I don't think we have anything for promoteds (and it seems non-trivial, we would need a way to force something to be promoted despite it violating the usual conditions).
Change:
let env_ptr_ty = Type::at_box(bcx.ccx(), Type::i8(bcx.ccx())).ptr_to(); let env = PointerCast(bcx, env, env_ptr_ty); with_cond(bcx, IsNotNull(bcx, env), |bcx| { <del> let dtor_ptr = GEPi(bcx, env, &[0u, abi::box_field_drop_glue]); </del> <ins> let dtor_ptr = GEPi(bcx, env, &[0u, abi::BOX_FIELD_DROP_GLUE]); </ins> let dtor = Load(bcx, dtor_ptr); Call(bcx, dtor, &[PointerCast(bcx, box_cell_v, Type::i8p(bcx.ccx()))], None); bcx

Discussion:
There are three versions of these layouts for functions, traits, and slices, but the compiler relies on these being the same. We should replace them with a single layout: and or something. While we're at it, we should probably find uses of len/length names in the DST code and replace it with something more generic.
I merged the constants. Could you elaborate on the length names? Are there more constants like these?
What still needs to be done here, if anything?
Looks done.
Change:
/// # Examples /// /// ``` <del> /// #![feature(cell_filter_map)] /// </del> /// use std::cell::{RefCell, RefMut}; /// /// let c = RefCell::new(vec![1, 2, 3]);

Discussion:
Feature gate: This is a tracking issue for and , which lets you optionally project data inside a or , wrapped in a or . If the projection returns then these methods return a so that you can still get the original or back out. [x] Implementation: [x] Final commenting period (FCP) [ ] Stabilization PRNaming and signature: We wanted to call this method and accept a closure like , but that's not sound with bound lifetimes. This method is only ok when the mapping closure uses HRTB. So we opted to call it instead, with the closure returning a .
I am in need of this API for my library in order to be able to have an efficient implementation that avoids unsafe Rust code. I wonder, why is the goal to have instead of since I can see a great value in having both APIs available. So if is already good to go we could stabilize that one and later add as soon as all open questions for it are resolved.
The name seems unusual for something that returns a - for example, returns an iterator with filtering built in. The equivalent method already exists in the Mutex implementations of , under the name . In both cases the closure it accepts returns and not the more general . So maybe the name should be reconsidered in that light.
I'm also interested in the stabilization of this API for the same reason as However, I also agree that should be named since it returns a . As an API user it makes more sense to me.
I wonder if we can have a generic filter & map for any inner enum instead of just Option. For example in this code As the code show, ref is compared twice to get the result. Is there any way to make it simpler?
fcp 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.
: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:
<ins> // Regression test for #106126. // check-pass // aux-build:issue-106126.rs #![deny(unsafe_op_in_unsafe_fn)] #[macro_use] extern crate issue_106126; foo!(); fn main() {} </ins>

Discussion:
In some external crate, say : Main crate: : With , this gives the following ICE: <details<summary<strongBacktrace</strong</summary<p</p</detailsThis is because the lint to insert the name in the diagnostic message (this delays a good path bug), then the lint because it's in an external macro, which means we don't emit any diagnostic which triggers the good path bug. This ICE is currently preventing rustc from building with enabled. I see several ways to fix this: don't print the function name. It arguably carries little value, with the span already pointing to the offending function call, and brings THIR unsafeck in line with MIR unsafeck (cc ). 't trim the path. This might lead to longer messages but other lints already do this so it is probably acceptable? 't create the lint if we're in an external macro and we know the lint will be cancelled anyway. It's a little hacky and breaks down if changes are made to lint emission. the lint emission API to allow lint messages to be lazily evaluated. label +A-diagnostics +requires-nightly claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Error: Label thir-unsafeck can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Would not trimming the path also be acceptable ? (via )
It looks like some lints are already not trimming paths so this is probably acceptable? I can do that if that's the preferred option.
claim
Change:
arg_counts.lifetimes, ) } else { <del> (false, None) </del> <ins> (reported_late_bound_region_err.unwrap_or(false), None) </ins> } }

Discussion:
Compiler crashes with Also, I wonder what is the right way (or is there any way) to write a with expected behavior. Thanks.
Reduced:
Regression first occurred in 1.30 according to godbolt.
One can leave out the trait in your MCVE, still crashes. Bug was introduced somewhere between ... Sadly that's a very big range, but there are no nightlys available in between and also no bors artifacts because they are older than 167
triage: P-high
Smaller example from :
I was trying to remove as many type parameters as possible, and ended up with this: Removing after still cuases an ICE. Adding a after stops causing the ICE. Removing the also stops causing the ICE. Not sure if it's any more or less helpful, but just putting this here.
claim Looks like that didn't work, either way, I'm taking a look into this issue.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Change:
<ins> // run-pass // regression test for issue #94923 // min-llvm-version: 15.0.0 // compile-flags: -C opt-level=3 fn f0<T>(mut x: usize) -> usize { for _ in 0..1000 { x *= 123; x %= 99 } x + 321 // function composition is not just longer iteration } fn f1<T>(x: usize) -> usize { f0::<(i8, T)>(f0::<(u8, T)>(x)) } fn f2<T>(x: usize) -> usize { f1::<(i8, T)>(f1::<(u8, T)>(x)) } fn f3<T>(x: usize) -> usize { f2::<(i8, T)>(f2::<(u8, T)>(x)) } fn f4<T>(x: usize) -> usize { f3::<(i8, T)>(f3::<(u8, T)>(x)) } fn f5<T>(x: usize) -> usize { f4::<(i8, T)>(f4::<(u8, T)>(x)) } fn f6<T>(x: usize) -> usize { f5::<(i8, T)>(f5::<(u8, T)>(x)) } fn f7<T>(x: usize) -> usize { f6::<(i8, T)>(f6::<(u8, T)>(x)) } fn f8<T>(x: usize) -> usize { f7::<(i8, T)>(f7::<(u8, T)>(x)) } fn main() { let y = f8::<()>(1); assert_eq!(y, 348); } </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. --I discovered a compiler error (segfault) in the following code () in which a generic function is called many times with different types. Some changes that avoid the crash: Running with debug mode instead of release Making simpler (e.g. or ) Marking as Removing the generics () Using the same type argument for all calls () For reference, I wrote the code in question because I was curious about whether the compiler would monomorphize multiple copies of the generic function for different types when the implementation does not depend on the type. <!-- 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. --: also the following versions on Rust playground: stable nightly See backtrace. The output looks the same to me and this was too long to submit with two copies. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label I-crash <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No longer ICEs since
claim
Change:
self.add_traits_in_parent_scope(impl_def_id); } } <ins> for (ty_def_id, impl_def_id) in all_inherent_impls { if self.resolver.cstore().visibility_untracked(ty_def_id) == Visibility::Public { self.add_traits_in_parent_scope(impl_def_id); } } </ins> self.all_traits.extend(all_traits); self.all_trait_impls.extend(all_trait_impls.into_iter().map(|(_, def_id, _)| def_id));

Discussion:
Running on nightly causes an ICE. Judging by my for PRs this broken between 2 and 4 days ago (26th-28th Jan). See attached minified project: . Essentially, this is: <details<summary<strongBacktrace</strong</summary<p</p</details
I see the same on Docs build fine with latest stable (1.58.1), but I get the same error with
This is probably a duplicate of , right? The fix for that () isn't in yesterday's (2022-01-29) nightly yet, but should be in today's.
I get the same error with , which does include .
works for me on aarch64-apple-darwin, but not on
There are definitely three crates still hitting this ICE on (at least based on message, and backtrace in 2 cases, but I couldn't reproduce on when testing locally) in
You can use () in your code to figure out what change caused this regression.
Not so surprisingly bisection reveals as the cause.
I'm not sure if this is helpful, but this is the stack I get when attempting to run rustdoc with nightly (which is the most recent nightly available on macOS). I also get the same build failure in CI with . This error comes from building the docs on
Fixed in
Assigning same priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
It seems this issue has regressed recently? Hitting the same ICE on . <details<summary<strongBacktrace</strong</summary<p</p</details
The recent regression should be fixed by , most likely.
Change:
for details)", "FEATURE"), optopt("", "android-cross-path", "The path to the Android NDK", "PATH"), <del> optflagopt("W", "warn", </del> <ins> optmulti("W", "warn", </ins> "Set lint warnings", "OPT"), optmulti("A", "allow", "Set lint allowed", "OPT"),

Discussion:
is supposed to work like , and which can appear multiple times.
I believe this was broken in . Tagging and
The change was meant to improve usability, since there was no hint that "-W help" exists. It should be reverted then.
If passing it more than once becomes possible, the ability to pass comma-separated warnings should probably be removed. It's strange to have that for lints but not for .
How do you pass comma separated warnings?
Ah, it was removed...
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-99073-2.rs:9:22 | LL | fn test<T: Display>(t: T, recurse: bool) -> impl Display { |                                             ------------ the expected opaque type LL |     let f = || { LL |         let i: u32 = test::<i32>(-1, false); |                      ^^^^^^^^^^^^^^^^^^^^^^ types differ | = note: expected opaque type `impl std::fmt::Display` found type `u32` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical