jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![warn(unused_attributes)] // Tests that placing the #[no_mangle] attribute on a foreign fn or static emits // a specialized warning. // The previous warning only talks about a "function or static" but foreign fns/statics // are also not allowed to have #[no_mangle] // build-pass extern "C" { #[no_mangle] //~^ WARNING `#[no_mangle]` has no effect on a foreign static //~^^ WARNING this was previously accepted by the compiler pub static FOO: u8; #[no_mangle] //~^ WARNING `#[no_mangle]` has no effect on a foreign function //~^^ WARNING this was previously accepted by the compiler pub fn bar(); } fn no_new_warn() { // Should emit the generic "not a function or static" warning #[no_mangle] //~^ WARNING attribute should be applied to a free function, impl method or static //~^^ WARNING this was previously accepted by the compiler let x = 0_u8; } fn main() {} </ins>

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 warning. Instead, this happened: ~The attribute is actually applied correctly, otherwise we would get undefined symbol error.~ Also, the extern variable is clearly declared as static, so the warning does not really make sense. Edit: it seems that the code also works without the attribute. So is the attribute actually not needed? Anyway, the warning about is confusing. This problem occurred in our embedded project , where the static global variables are used to provide references to linker symbols. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.47 stable. Haven't tried newer nightly. : modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, this is working correctly. does nothing on extern items, which already do not get mangled, even without the attribute.
OK, sorry for not understanding the behavior of on extern items.
So maybe this should not be marked as regression, this is just a confusing but indeed correct warning message. Is there a way to remove the labels?
claim
Change:
keep_space: (bool, bool), ) { let primary_span = if let Some((lo, hi)) = spans { <ins> if hi.is_empty() { // do not point at delims that do not exist return; } </ins> MultiSpan::from(vec![lo, hi]) } else { MultiSpan::from(value_span)

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced:
reduced further claim I think try to get a span from to but we work around and assume that since we don't have a , it must be somewhere near EOF. When we then try to point at it via diagnostics, we get the error that we don't have anything to actually point to.
Change:
) } <ins> /// Checks if the node is left-hand side of an assignment. pub fn is_lhs(&self, id: HirId) -> bool { match self.find(self.get_parent_node(id)) { Some(Node::Expr(expr)) => match expr.kind { ExprKind::Assign(lhs, _rhs, _span) => lhs.hir_id == id, _ => false, }, _ => false, } } </ins> /// Whether the expression pointed at by `hir_id` belongs to a `const` evaluation context. /// Used exclusively for diagnostics, to avoid suggestion function calls. pub fn is_inside_const_context(&self, hir_id: HirId) -> bool {

Discussion:
I try this code: () I expect to see this happen: No invalid suggestion for . Instead, I got this errors: label D-invalid-suggestion T-compiler
Change:
/// Is the token `dist` away from the current suitable as the start of a range patterns end? fn is_pat_range_end_start(&self, dist: usize) -> bool { <del> self.look_ahead(dist, |t| { t.is_path_start() // e.g. `MY_CONST`; </del> <ins> self.check_inline_const(dist) || self.look_ahead(dist, |t| { t.is_path_start() // e.g. `MY_CONST`; </ins> || t.kind == token::Dot // e.g. `.5` for recovery; || t.can_begin_literal_maybe_minus() // e.g. `42`. || t.is_whole_expr() <del> }) </del> <ins> }) </ins> } fn parse_pat_range_end(&mut self) -> PResult<'a, P<Expr>> { <del> if self.check_path() { </del> <ins> if self.check_inline_const(0) { self.parse_const_block(self.token.span) } else if self.check_path() { </ins> let lo = self.token.span; let (qself, path) = if self.eat_lt() { // Parse a qualified path

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
), ); } <del> for (_, target) in targets.iter() { </del> <ins> let target_width = self.tcx.sess.target.pointer_width; let size = Size::from_bits(match switch_ty.kind() { ty::Uint(uint) => uint.normalize(target_width).bit_width().unwrap(), ty::Int(int) => int.normalize(target_width).bit_width().unwrap(), ty::Char => 32, ty::Bool => 1, other => bug!("unhandled type: {:?}", other), }); for (value, target) in targets.iter() { if Scalar::<()>::try_from_uint(value, size).is_none() { self.fail( location, format!("the value {:#x} is not a proper {:?}", value, switch_ty), ) } </ins> self.check_edge(location, target, EdgeKind::Normal); } self.check_edge(location, targets.otherwise(), EdgeKind::Normal);

Discussion:
Hypothetically we could have a we expect this not to happen, so this is an invariant of MIR that we can check cc
Change:
use super::*; use crate::env; <ins> use crate::rc::Rc; </ins> use crate::sync::mpmc::SendTimeoutError; use crate::thread; use crate::time::Duration;

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: I expected to see the struct in the Sender buffer get dropped after the Receiver is dropped during the unwind of the panicking thread. Instead, this happened: The data in the Sender buffer is not dropped until the whole process ends. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.66.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
bisection seems to point to cc searched nightlies: from nightly-2022-11-01 to nightly-2023-02-01 regressed nightly: nightly-2022-11-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
In crossbeam, the unbounded channel does this (), but the bounded channel does not. There is no particular intent, it just hasn't been implemented. cc
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/102467>. // It ensures that the expected error is displayed. #![feature(associated_const_equality)] trait T { type A: S<C<X = 0i32> = 34>; //~^ ERROR associated type bindings are not allowed here } trait S { const C: i32; } 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. --./src/test/ui/associated-consts/issue-- <!-- 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. --: rustdoc ./src/test/ui/associated-consts/issue-- <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
For an unknown reason, it doesn't fail before we're way into the part of rustdoc when calling .
I tried this: <details</detailsBut unfortunately the result still looks bad: Not sure what's going on and why this error appears this late.
Hm, is it worth committing that? :slightlysmilingface: In other examples like we don't get any information at all on what the underlying error is and rustdoc just says I know that there are perhaps 5-10 ices that all have this message and its hard for me to tell if they all have the same cause or are actually due to different underlying issues. :/
I can provide a PR with this change if you want, but I'm not sure it's much of an improvement... Oh well. Pushing a PR and then you'll decide if you want it or not.
This errors correctly on rustdoc now, needs test
I'll add it tomorrow then. Thanks for the heads up!
Change:
GenericArgKind::Const(ct) => { match ct.kind() { ty::ConstKind::Unevaluated(uv) => { <del> let obligations = self.nominal_obligations(uv.def.did, uv.substs); self.out.extend(obligations); let predicate = ty::Binder::dummy(ty::PredicateKind::ConstEvaluatable(ct)); let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.param_env, predicate, )); </del> <ins> if !ct.has_escaping_bound_vars() { let obligations = self.nominal_obligations(uv.def.did, uv.substs); self.out.extend(obligations); let predicate = ty::Binder::dummy(ty::PredicateKind::ConstEvaluatable(ct)); let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.param_env, predicate, )); } </ins> } ty::ConstKind::Infer(_) => { let cause = self.cause(traits::WellFormed(None));

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 --
Can you add the to the code example instead to make it more easily runnable in the future?
claim
Change:
// involved or not, library reordering and kind overriding without // explicit `:rename` in particular. if lib.has_modifiers() || passed_lib.has_modifiers() { <del> self.tcx.sess.span_err( self.tcx.def_span(lib.foreign_module.unwrap()), "overriding linking modifiers from command line is not supported" ); </del> <ins> let msg = "overriding linking modifiers from command line is not supported"; match lib.foreign_module { Some(def_id) => self.tcx.sess.span_err(self.tcx.def_span(def_id), msg), None => self.tcx.sess.err(msg), }; </ins> } if passed_lib.kind != NativeLibKind::Unspecified { lib.kind = passed_lib.kind;

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. --There is no code. The internal compiler error happens when building rustc itself (on MSYS2/Mingw) <!-- 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. --We are trying to build Rust 1.61.0. The error happens when building while processing the libs passed on the command line. The issue concerns native library modifiers and was most probably introduced by The line that triggers the panic is here: The code change in question broke the handling of (i.e. no bundle) which is used when building on mingw. See here for an example: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Note that we have on the rustc command line. So we have the same lib twice and one has modifiers which triggers the error. It should actually trigger an error but panics before...
Yes, the ICE is caused by used to determine the span for the error. There's a PR in progress that fixes that - Even without ICE you'll need a workaround for the error that it's masking - linking the library with modifiers either only from command line, or only from attributes. will relax these restrictions as well.
The ICE is a regression from
Fixed in
Change:
pub compiler_builtins: Option<CrateNum>, pub profiler_runtime: Option<CrateNum>, pub is_no_builtins: FxHashSet<CrateNum>, <del> pub native_libraries: FxHashMap<CrateNum, Lrc<Vec<NativeLib>>>, </del> <ins> pub native_libraries: FxHashMap<CrateNum, Vec<NativeLib>>, </ins> pub crate_name: FxHashMap<CrateNum, String>, <del> pub used_libraries: Lrc<Vec<NativeLib>>, </del> <ins> pub used_libraries: Vec<NativeLib>, </ins> pub link_args: Lrc<Vec<String>>, pub used_crate_source: FxHashMap<CrateNum, Lrc<CrateSource>>, pub used_crates_static: Vec<(CrateNum, LibSource)>,

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 command: I expected to see this happen: An file is generated. Instead, this happened: <!-- 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.
Change:
/// assert!(!(..=1.0).contains(&f32::NAN)); /// assert!(!(..=f32::NAN).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

Discussion:
I tried this code: Also godbolt link I expected to see this happen: I was trying this code to see what kind of assemble the compilers makes. I tried different optimize levels. I see with optimize levels and , that the bits are still there but not used in the function. function is self takes about 5 instructions and the code about 40 instruction, which is dead code. Instead, this happened: bits removed in all the optimize levels. I was using a similar code on a embedded device. FYI: It also happens with . Remove the before 247. I see this happen on stable and nightly both for x86_64 and thumbv6/v7.
This is, unfortunately, well known. and aren't necessarily smaller 'll be optimized out in (which is opt-level=2).
Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.
maybe to clarify. With opt_level the assembly of the generated function is fine and optimized. But the bits are not removed and not used. so I am not sure if will help in this case.
does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the output to just one function.
Change:
yield_data.source); // If unresolved type isn't a ty_var then unresolved_type_span is None <ins> let span = self.prev_unresolved_span.unwrap_or_else( || unresolved_type_span.unwrap_or(source_span) ); </ins> self.fcx.need_type_info_err_in_generator( self.kind, <del> unresolved_type_span.unwrap_or(source_span), </del> <ins> span, </ins> unresolved_type, ) .span_note(yield_data.span, &*note)

Discussion:
Consider for example this code (using ): This code will fail to compile due to types which cannot be fully inferred, with an error like this: However neither of these spans are anywhere near to the real problem which is the fact that variant is not inferred for . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
assign will do some investigation here and see if they can get an idea what's going on (and maybe fix)
Change:
clean::TypedefItem(ref t) => item_typedef(fmt, self.item, t), clean::MacroItem(ref m) => item_macro(fmt, self.item, m), clean::PrimitiveItem(ref p) => item_primitive(fmt, self.item, p), <ins> clean::StaticItem(ref i) => item_static(fmt, self.item, i), clean::ConstantItem(ref c) => item_constant(fmt, self.item, c), </ins> _ => Ok(()) } }

Discussion:
Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !
Change:
let decl = self.parse_fn_block_decl()?; let decl_hi = self.prev_span; let body = match decl.output { <del> FunctionRetTy::Default(_) => self.parse_expr()?, </del> <ins> FunctionRetTy::Default(_) => { let restrictions = self.restrictions - RESTRICTION_STMT_EXPR; self.parse_expr_res(restrictions, None)? }, </ins> _ => { // If an explicit return type is given, require a // block to appear (RFC 968).

Discussion:
Currently is parsed as . I think it should be parsed as , to be consistent with handling of other similar "open" binary and prefix expressions (lambdas can be viewed as a form of a prefix expression). Consider these expressions: They are parsed as The last two cases seem to be different from others and wrong. on IRC suggested that this behavior could have been introduced accidentally during transition from lambdas with blocks as bodies to lambdas with arbitrary expressions as bodies. If this is a bug, fixing it can render some previously valid programs invalid, but this seems rater unlikely, as bare lambdas rarely end up in conditionals. It is possible though:
cc
Oh and I didn't mean I had introduced the distinction accidentally but rather that before I made that simplification, the code was block-oriented so the need for it to obey typical expression rules may have been overlooked and I didn't think about it (to consider fixing it).
Change:
<ins> //@ check-pass #![feature(rust_cold_cc)] // extern "rust-cold" is a "Rust" ABI so we accept `repr(Rust)` types as arg/ret without warnings. pub extern "rust-cold" fn f(_: ()) -> Result<(), ()> { Ok(()) } extern "rust-cold" { pub fn g(_: ()) -> Result<(), ()>; } fn main() {} </ins>

Discussion:
() Like and the other ABIs, should not trigger and for non-FFI-safe types. Related: , ; tracking issue . No response No response_
Change:
v.remove(1); v.pop().unwrap(); assert_eq!(*v0, 13); <ins> v.push(1); v.swap_remove(1); assert_eq!(v.len(), 2); v.swap_remove(1); // swap_remove the last element assert_eq!(*v0, 13); // Appending v.append(&mut vec![27, 19]); assert_eq!(*v0, 13); // Extending v.extend_from_slice(&[1, 2]); v.extend(&[1, 2]); // `slice::Iter` (with `T: Copy`) specialization v.extend(vec![2, 3]); // `vec::IntoIter` specialization v.extend(std::iter::once(3)); // `TrustedLen` specialization v.extend(std::iter::empty::<i32>()); // `TrustedLen` specialization with empty iterator v.extend(std::iter::once(3).filter(|_| true)); // base case v.extend(std::iter::once(&3)); // `cloned` specialization assert_eq!(*v0, 13); // Truncation v.truncate(2); assert_eq!(*v0, 13); // Resizing v.resize_with(v.len() + 10, || 42); assert_eq!(*v0, 13); v.resize_with(2, || panic!()); assert_eq!(*v0, 13); // No-op reservation v.reserve(32); v.reserve_exact(32); assert_eq!(*v0, 13); // Partial draining v.resize_with(10, || 42); next_then_drop(v.drain(5..)); assert_eq!(*v0, 13); // Splicing v.resize_with(10, || 42); next_then_drop(v.splice(5.., vec![1, 2, 3, 4, 5])); // empty tail after range assert_eq!(*v0, 13); next_then_drop(v.splice(5..8, vec![1])); // replacement is smaller than original range assert_eq!(*v0, 13); next_then_drop(v.splice(5..6, vec![1; 10].into_iter().filter(|_| true))); // lower bound not exact assert_eq!(*v0, 13); // Smoke test that would fire even outside Miri if an actual relocation happened. *v0 -= 13; assert_eq!(v[0], 0); </ins> } // https://github.com/rust-lang/rust/pull/49496 introduced specialization based on:

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up: