jiebi/CodeConvo huggingface dataset:
Change:
target_option_val!(default_hidden_visibility); target_option_val!(embed_bitcode); target_option_val!(emit_debug_gdb_scripts); <ins> target_option_val!(requires_uwtable); </ins> if default.abi_blacklist != self.options.abi_blacklist { d.insert("abi-blacklist".to_string(), self.options.abi_blacklist.iter()

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
attempt to use a non-constant value in a constant .suggestion = try using `Self` <ins> resolve_macro_defined_later = a macro with the same name exists, but it appears later at here </ins> resolve_macro_expected_found = expected {$expected}, found {$found} `{$macro_path}`

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
.collect::<SmallVec<[RegionId; 8]>>(); // Sort the id list so that the algorithm is deterministic ids.sort_unstable(); <ins> ids.dedup(); </ins> let ids = ids; match &ids[..] { // Create a new connected region

Discussion:
's stm32f4 is failing:
I suspect this is caused by , merged in (rollup) and root PR -- is this expected breakage (i.e., code in stm32f4 is unsound/should never have been accepted)?
Change:
<ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} //~^ ERROR: invalid value for constraint in inline assembly } } </ins>

Discussion:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

I'm experimenting with a parser combinator and ran into an issue with closure lifetime inference. This might be a duplicate of , since it uses a similar (but simpler) mechanism to produce the same error message. However, in the code below the error is potentially a lot further away, and since I need to return values from the closure I'm having trouble finding any way to make it work by explicitly specifying a signature. Since it involves more moving parts, I'm also not sure how to confirm if the underlying issue is the same. I removed all parts that aren't involved in triggering the error message (the original use case has trait methods with related return types). It comes down to the following error message: And here is the triggering code:
After some experimentation, I tried a possible fix, which lead to an ICE. I changed to which gives me: My is: And here is the :
The ICE reduced:
Triage: still ICEs
Still ICEs:
The reduced example doesn't show the ICE, from 1.35.0 (tested on godbolt). Marked as E-needstest
And the original code is now accepted, so adding tests is enough to close this ticket.
Change:
&format!("`#[doc(alias = "...")]` isn't allowed on {}", err), ) .emit(); <ins> return false; </ins> } } }

Discussion:
From this comment: Still remaining the .
Actually, the character has a meaning in the search (for "exact" search). But instead of just removing it, maybe we should instead emit an error when we encounter it. What do you think ?
That doesn't work for though, maybe it should? It would make sense to restrict allowed characters because even whitespace is allowed at the moment which seems questionable.
It sounds like we need to make sure this lands before we branch beta or so?
Let's forbid , whitespaces and tabs in the the doc alias then.
Can we avoid ad-hoc rules and say something like "must be a rust identifier"?
Even better! Great suggestion !
Just thought about it, but it cannot be the case : we allow things like "*" or "+" (for the traits for example), so it cannot be ident only. I'll stick to the listed characters above.
The documentation () has no mention of that -- can you elaborate?
Doc aliases can be something else than a rust identifier. For example, you can look for or in the std docs, and you'll see aliases results.
Ah, I see what you mean. Okay, then I agree that we need more than just Rust identifiers, and it might be reasonable to just allow as you suggest -- everything except whitespace and quotes. I'm a bit worried that'll hurt us in terms of how expansive it is but it's probably fine.
I don't expect attributes to be used widely, so we should be fine. ;)
Is there more justification for removing whitespace support other than calling the characters questionable? If I have a struct or a function that implements an algorithm, I would like to alias the item to the plaintext name of the algorithm, for example .
I just had in mind "idents", so no whitespace in them. However I don't see any reason to not allow specfically. I'll send a PR tomorrow.
rustdoc only being ident-centric is .
path-centric would be more accurate. ;)
Change:
self.0.destroy() } } <del> // the cfg annotations only exist due to dead code warnings. the code itself is portable #[cfg(unix)] pub struct StaticRWLock(RWLock); #[cfg(unix)] impl StaticRWLock { pub const fn new() -> StaticRWLock { StaticRWLock(RWLock::new()) } /// Acquires shared access to the underlying lock, blocking the current /// thread to do so. /// /// The lock is automatically unlocked when the returned guard is dropped. #[inline] pub fn read_with_guard(&'static self) -> RWLockReadGuard { // SAFETY: All methods require static references, therefore self // cannot be moved between invocations. unsafe { self.0.read(); } RWLockReadGuard(&self.0) } /// Acquires write access to the underlying lock, blocking the current thread /// to do so. /// /// The lock is automatically unlocked when the returned guard is dropped. #[inline] pub fn write_with_guard(&'static self) -> RWLockWriteGuard { // SAFETY: All methods require static references, therefore self // cannot be moved between invocations. unsafe { self.0.write(); } RWLockWriteGuard(&self.0) } } #[cfg(unix)] pub struct RWLockReadGuard(&'static RWLock); #[cfg(unix)] impl Drop for RWLockReadGuard { fn drop(&mut self) { unsafe { self.0.read_unlock() } } } #[cfg(unix)] pub struct RWLockWriteGuard(&'static RWLock); #[cfg(unix)] impl Drop for RWLockWriteGuard { fn drop(&mut self) { unsafe { self.0.write_unlock() } } } </del>

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:
let (res, innermost_res) = (binding.res(), innermost_binding.res()); if res != innermost_res { let builtin = Res::NonMacroAttr(NonMacroAttrKind::Builtin); <del> let derive_helper = Res::NonMacroAttr(NonMacroAttrKind::DeriveHelper); </del> <ins> let is_derive_helper_compat = |res, flags: Flags| { res == Res::NonMacroAttr(NonMacroAttrKind::DeriveHelper) && flags.contains(Flags::DERIVE_HELPER_COMPAT) }; </ins> let ambiguity_error_kind = if is_import { Some(AmbiguityKind::Import) } else if innermost_res == builtin || res == builtin { Some(AmbiguityKind::BuiltinAttr) <del> } else if innermost_res == derive_helper || res == derive_helper { </del> <ins> } else if is_derive_helper_compat(innermost_res, innermost_flags) || is_derive_helper_compat(res, flags) { </ins> Some(AmbiguityKind::DeriveHelper) } else if innermost_flags.contains(Flags::MACRO_RULES) && flags.contains(Flags::MODULE) &&

Discussion:
So pointed out to me that some recent changes in name resolution seem to have broken . They pointed me at dealing with the fallout -- maybe you can leave a few notes as to what errors you were seeing before this commit? cc -- could this be the recent changes around name resolution of helper attributes in macros? It seems the relevant code is stuff like:
(Nominated for discussion around the breakage policy/implications here.)
Duplicate of , I'll prepare a fix.
fix Or rather a "tiebreaker" for the ambiguity, since both names are indeed in scope and create ambiguity, which is correctly detected after .
Fixed in

This is a dependency of . I was trying to compile ; it failed on both the master branch and the current published version. is ambiguous (derive helper attribute vs any other name) Indeed, the code does seem to treat as simultaneously a derive macro and an attribute macro. It works fine on stable.
Example of failing builds:
modify labels: +E-needs-bisection It'd be nice if somebody pinpointed specific PR (or nightly at least). Maybe has a clue what could have caused it.
Seems to be introduced at nightly-2019-11-17. Unfortunately I'm not able to bisect that further because cargo-bisect-rustc is telling me:
Likely
This is a consequence of , I'll provide a ASAP.
Fixed in
Change:
<ins> // no-prefer-dynamic #![crate_type = "lib"] pub fn empty() {} </ins>

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
)); } } else { <del> let callee_layout = self.layout_of_local(self.frame(), mir::RETURN_PLACE, None)?; if !callee_layout.abi.is_uninhabited() { return err!(FunctionRetMismatch( self.tcx.types.never, callee_layout.ty )); </del> <ins> let local = mir::RETURN_PLACE; let ty = self.frame().body.local_decls[local].ty; if !self.tcx.is_ty_uninhabited_from_any_module(ty) { return err!(FunctionRetMismatch(self.tcx.types.never, ty)); </ins> } } Ok(())

Discussion:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.
Change:
let open_details = |close_tags: &mut String| { if toggled { close_tags.insert_str(0, "</details>"); <del> "<details class="rustdoc-toggle implementors-toggle" open><summary>" </del> <ins> "<details class="rustdoc-toggle implementors-toggle"><summary>" </ins> } else { "" }

Discussion:
beta and nightly ignore the default-on configuration of "Auto-hide trait implementation documentation" On stable  looks like: ! While it looks like: ! And (as of 2021-05-17): ! Going to and toggling "Auto-hide trait implementation documentation" off makes stable look the same as beta, so it definitely seems like beta/nightly are just ignoring this toggle.
This is due to the refactoring we've been doing with the expand / collapse toggles, wrapping them in tags. The code that expands and collapses them based on settings is here: You can see there's an entry for handling "implementors" but not one for "implementations." Right now, both implementors and implementations get wrapped in a tag with . We need to update this Rust code: So that it generates for implementors and for implementations. And then update the JS to add a clause for implementations.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I'm having trouble figuring out what fields to check in to figure out if we're rendering an implementor or an implementation. If someone's able to point me in the right direction I'd appreciate it!
Well, I think I handled it in (funny that I was noticed it and fixed it on my side and someone else find it out too).
Change:
fn level_src(&self, lint: &'static Lint) -> Option<LevelSource> { self.lints().levels.get(&LintId::of(lint)).map(|ls| match ls { <del> &(Warn, src) => { </del> <ins> &(Warn, _) => { </ins> let lint_id = LintId::of(builtin::WARNINGS); <del> (self.lints().get_level_source(lint_id).0, src) </del> <ins> let warn_src = self.lints().get_level_source(lint_id); if warn_src.0 != Warn { warn_src } else { *ls } </ins> } _ => *ls })

Discussion:
Normally, an unused import: Produces this compiler output: Saying the 'unusedimports' lint is 'on by default'. If you explicitly set that lint to deny: Then the error indicates where the lint was set to 'deny': If you instead change warnings to errors: Then you get this error: Which says 'deny(unusedimports)' is 'on by default'. That is not true. unused_imports is warn by default. This case should point to as the source of the error. Discovered while interpreting all the lint regressions in . cc
I took a shot at this and made a PR. Now your example code for deny(warnings) shows the following:
This was fixed by .
Change:
/// It is required that the keys implement the `Eq` and `Hash` traits, although /// this can frequently be achieved by using `#[derive(Eq, Hash)]`. /// <ins> /// It is a logic error for a key to be modified in such a way that the key's /// hash, as determined by the `Hash` trait, or its equality, as determined by /// the `Eq` trait, changes while it is in the map. This is normally only /// possible through `Cell`, `RefCell`, global state, I/O, or unsafe code. /// </ins> /// Relevant papers/articles: /// /// 1. Pedro Celis. ["Robin Hood Hashing"](https://cs.uwaterloo.ca/research/tr/1986/CS-86-14.pdf)

Discussion:
Collections that perform lookups based on a given property (e.g. a hash or an ordering) can be put into an inconsistent state when the property changes while its corresponding item is in the collection. This is normally not a problem, because such collections (at least those in ) do not provide mutable access to the type from which the property is derived (keys in the case of maps, items in the case of sets), but types with interior mutability can induce this behavior in safe code: Output: This is obvious from the definition of interior mutability, but it's definitely a footgun. If the use of such keys cannot be prevented with the type system, the collections should at least document that the property must remain constant for the duration of the item's presence in the collection. For example, Java's contains the following note:
This is a dupe of , which was for reasons in the thread itself. I believe the gist of the conversion was that yes, this can happen. Our implementations should ensure that this does not cause memory unsafety, but otherwise these sorts of "odd assertions" are ok to happen as this should be quite a rare occurrence anyway.
I still think the collection documentation needs to identify this problem. On Friday, March 13, 2015, Alex Crichton wrote:
Hm good point! I've an appropriate tag.
I'm working on a patch to document this.
Change:
fn visit_block(&mut self, b: &hir::Block) { run_lints!(self, check_block, late_passes, b); hir_visit::walk_block(self, b); <ins> run_lints!(self, check_block_post, late_passes, b); </ins> } fn visit_arm(&mut self, a: &hir::Arm) {

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
display_fn(move |f| match self.did { Some(did) => resolved_path(f, did, &self.path, true, false), _ => { <del> for (i, seg) in self.path.segments.iter().enumerate() { if i > 0 { write!(f, "::")? } write!(f, "{}", seg.name)?; </del> <ins> for seg in &self.path.segments[..self.path.segments.len() - 1] { write!(f, "{}::", seg.name)?; } let name = self.path.last_name(); if let hir::def::Res::PrimTy(p) = self.path.res { primitive_link(f, PrimitiveType::from(p), name)?; } else { write!(f, "{}", name)?; </ins> } Ok(()) }

Discussion:
When re-exporting a primitive type, rustdoc ICEs. This was found when creating . Rustdoc also fails to link the re-export to the primitive docs. Reproduction: commands: Backtrace:
I plan on investigating this issue tomorrow, as it is likely a blocker for
-- this is blocking , and I was unable to come up with a simple patch to fix this. Is this a known-hard problem, or should I try to keep digging? contains my initial patch, but it fails tests (e.g., auto impls for primitives, among other problems).
I'll try to take a look shortly. And no, never heard of it before you opened this issue. Don't hesitate to ping me if I forget.
Change:
RetagKind, RuntimePhase, Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, UnOp, START_BLOCK, }; <del> use rustc_middle::ty::{self, InstanceDef, ParamEnv, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, InstanceDef, ParamEnv, Ty, TyCtxt, TypeVisitable}; </ins> use rustc_mir_dataflow::impls::MaybeStorageLive; use rustc_mir_dataflow::storage::always_storage_live_locals; use rustc_mir_dataflow::{Analysis, ResultsCursor};

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response
searched toolchains through Regression in
I wonder if this is cc ?
very likely :thinking: will revert if we don't figure out how to fix this in the near future
<details<summarycompiler logs</summary</detailsedit: my bad I'm experiencing
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection tested with , seems to point to commit searched nightlies: from nightly-2023-01-15 to nightly-2023-02-09 regressed nightly: nightly-2023-01-27 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: </detailsit's a rollup of:
I already bisected this one (see second comment :D) any should we revert now? it's still ICEing
yeah, wanted to revert this since looking at this a few days ago :sweat_smile: but for that I want to update the comment for why we're avoiding opaque types which is effort, so I've put it off for a while. Should get to it over the next few days
Change:
<ins> // Copyright 2012 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. #[derive(Debug)] #[repr(i32)] enum E { Min = -2147483648i32, _Max = 2147483647i32, } fn main() { assert_eq!(Some(E::Min).unwrap() as i32, -2147483648i32); } </ins>

Discussion:
Rust 1.23.0 correctly prints . Rust 1.24.0 incorrectly prints . Mentioning because this sounds potentially relevant to or follow-on optimization. (Discovered by in #rust.)
Clearly from rather than a followup, as it's happening in nightly-2017-11-21 and not in nightly-2017-11-20.
This is not specific to but to the enum using both signed extremums of its representation type:
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-77218.rs:3:11 | LL |     while Some(0) = value.get(0) { |           ^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found `()` | help: you might have meant to use pattern matching | LL |     while let Some(0) = value.get(0) { |           ^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
I thought this code would provide one of the nice suggestions that implemented in , but it doesn't. (By the way, making a reference to will give an ICE because of .) () Errors:
Reopening as per
This is fixed in beta now: It is still quite verbose (too many errors), but we lead people in the right direction.

: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed in
Cc
Related: this code should probably have a suggestion for (): Currently it produces:
Minimized (): I think this might be caused by the lifetimes.
Never mind! This causes it too, with no lifetimes (): EDIT: removed the type aliases EDIT 2: changed to to make it clearer that they don't need to be the same type EDIT 3: shortened names, removed comment
Assigning and removing as .20.3D.20.2E.2E.2E.60.20expression.E2.80.A6) in the prioritization working group.
Further minimized to this (): Having be a or produces the ICE, but making it an owned does not produce the ICE.
causes the operands to be typechecked twice: I think this has side effects that are causing problems by being applied twice. Commenting out the second makes the ICE go away, but I'm not sure what the best approach for a proper fix is. The effect on the UI suite is rather low: (It still emits this error:)
I tried a couple of things but it seems to me that you hit the nail in the head and we just need to remove the branch. this is caused because one side is seen to be while the other is seen to be or (depending on the case). This is a problem because the left hand side expression should in reality be a pattern instead, but there's no utility to build a pattern from an expression: patterns are built during parsing (due to differences like, being a valid thing there). Because of that it'll be very hard to make the suggestion happen for those cases, much harder than for the ones we already handle.
I think I just found a smaller example (granted, it's not valid code any more, but how is one supposed to know that in case of ICE? ;-) ): (If that's not the same error I'm happy to open a new ICE issue, but to me it looks the same, with all the , the panic at and the conditional destructuring in a loop).