Rust Compiler Team
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • Write
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
    • Invite by email
      Invitee

      This note has no invitees

    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Note Insights
    • Engagement control
    • Transfer ownership
    • Delete this note
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Versions and GitHub Sync Note Insights Sharing URL Help
Menu
Options
Engagement control Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
Write
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
  • Invite by email
    Invitee

    This note has no invitees

  • Publish Note

    Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

    Your note will be visible on your profile and discoverable by anyone.
    Your note is now live.
    This note is visible on your profile and discoverable online.
    Everyone on the web can find and read all notes of this public team.
    See published notes
    Unpublish note
    Please check the box to agree to the Community Guidelines.
    View profile
    Engagement control
    Commenting
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Suggest edit
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    Emoji Reply
    Enable
    Import from Dropbox Google Drive Gist Clipboard
       owned this note    owned this note      
    Published Linked with GitHub
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    <!-- stubs generated with pcr-util --> # 2024 Q3 T-compiler P-high Issue Review Pre-triage *Issues snapshot collected at 2024-11-13 14:34:37.3713428 +00:00:00* Pre-triage done by: @jieyouxu [tracking-float-abi]: https://github.com/rust-lang/rust/issues/116344 ## P-high missing team label [P-high issues without team label](https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3AP-high%20-label%3AT-cargo%20-label%3AT-community%20-label%3AT-compiler%20-label%3AT-core%20-label%3AT-crates-io%20-label%3AT-dev-tools%20-label%3AT-docs-rs%20-label%3AT-infra%20-label%3AT-libs%20-label%3AT-libs-api%20-label%3AT-release%20-label%3AT-release%20-label%3AT-rustdoc%20-label%3AT-style%20-label%3AT-types%20-label%3AT-lang) **Did not find P-high issues without a team label** ## P-high T-compiler issues missing owner (no WG and no assignee) [P-high issues with no owner](https://github.com/rust-lang/rust/issues?q=is%3Aissue%20is%3Aopen%20label%3AT-compiler%20label%3AP-high%20-label%3Awg-debugging%20-label%3AWG-embedded%20-label%3AWG-diagnostics%20-label%3AWG-async%20-label%3AWG-incr-comp%20no%3Aassignee%20sort%3Acreated-asc%20-label%3AI-types-nominated%20-label%3AI-lang-nominated%20-label%3AI-compiler-nominated%20-label%3AT-types%20-label%3AWG-llvm) ### #131960: Regression: geoarrow crate does not compile in release mode on 1.82 Link: <https://github.com/rust-lang/rust/issues/131960> Creation date: 2024-10-20 Labels: `A-mir-opt-inlining`, `C-bug`, `P-high`, `T-compiler`, `T-types`, `regression-from-stable-to-stable` Author: `theemathas` Working groups: Assignees: Pre-triage notes: - MIR opt inlining cycle avoidance problem, hard to solve, good solution unclear, cc <https://github.com/rust-lang/rust/issues/131960#issuecomment-2425525940>. - Possibly knowledgeable people to consult: compiler-errors ### #131058: The (stable) `neon` aarch64 target feature is unsound: it changes the float ABI Link: <https://github.com/rust-lang/rust/issues/131058> Creation date: 2024-09-30 Labels: `A-ABI`, `A-rust-for-linux`, `A-target-feature`, `C-bug`, `I-unsound`, `P-high`, `T-compiler` Author: `RalfJung` Working groups: Assignees: Pre-triage notes: - Generic problem class of target feature ABI compatibility checks. - cc [Figure out which target features affect float ABI #131799][tracking-float-abi] - cc [The ABI of float types can be changed by -Ctarget-feature #116344](https://github.com/rust-lang/rust/issues/116344) - Possibly knowledgeable people to consult: Jubilee, bjorn3, RalfJung, aarch64 target maintainers - Triage question: I seem to recall interested people wanted to have some kind of design meeting for this? I can't find any design meeting proposal for this, did it fall through the cracks? ### #130853: Miscompile in the GVN transform Link: <https://github.com/rust-lang/rust/issues/130853> Creation date: 2024-09-25 Labels: `A-codegen`, `A-mir-opt`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler` Author: `jwong101` Working groups: Assignees: Pre-triage notes: - cjgillot already has a PR for this <https://github.com/rust-lang/rust/pull/132461> to gate the unjustified transform behind `-Zunsound-mir-opts`, example in issue is included as a test case. [Quote from PR description](https://github.com/rust-lang/rust/pull/132461#issue-2629255783): > The pass as written does not differentiate single deref or nested derefs, so I'm gating the entire unification on -Zunsound-mir-opts. This has the unfortunate effect of preventing reading from statics. Pre-triage action: - Assigned #130853 to cjgillot since they have a PR open for it already. ### #130834: Invalid metadata for arm64e due to Xcode 15+ on ARM64e macOS Link: <https://github.com/rust-lang/rust/issues/130834> Creation date: 2024-09-25 Labels: `C-bug`, `O-Arm`, `O-macos`, `P-high`, `T-bootstrap`, `T-compiler`, `regression-untriaged` Author: `arttet` Working groups: Assignees: Pre-triage notes: - `arm64e-apple-darwin` is a [Tier 3 target](https://doc.rust-lang.org/rustc/platform-support/arm64e-apple-darwin.html) as of time of pre-triage. - AFAICT this doesn't affect the `x86_64` and `aarc64` Tier 1 apple targets. Pre-triage recommendation: - No P-* because Tier 3 target. ### #129585: asm: Since nightly-2024-08-01 (LLVM 19), in and out is sometime allocated to the same register Link: <https://github.com/rust-lang/rust/issues/129585> Creation date: 2024-08-25 Labels: `A-LLVM`, `A-inline-assembly`, `C-bug`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler`, `llvm-fixed-upstream`, `regression-untriaged` Author: `taiki-e` Working groups: Assignees: Pre-triage remark (follow-up from nikic): > The mitigation was for the atomic-maybe-uninit crate (rather than rustc) and has already been implemented. So this issue is basically just waiting on the LLVM 20 release so we can close it for good. Pre-triage notes: - LLVM upstream bug but change is too extensive to backport to LLVM 19. - ~~We'll need to mitigate this downstream by "laundering the possibly-uninitialized inputs through a black_box" which "should prevent LLVM from incorrectly allocating the registers" (see quote below).~~ EDIT: superseded by nikic's remark (see above) - ~~No concrete assignee yet to drive the mitigation forward.~~ EDIT: superseded by nikic's remark (see above) See [nikic's comment](https://github.com/rust-lang/rust/issues/129585#issuecomment-2360273081): > This is fixed upstream now, but the required changes were fairly extensive, so this won't get backported to LLVM 19. I'd suggest working around this by laundering the possibly-uninitialized inputs through a black_box. That should prevent LLVM from incorrectly allocating the registers. Pre-triage action: - Added `WG-llvm` label as well. Pre-triage recommendation: - Add label `S-waiting-for-LLVM` (to wait for LLVM 20 release), see nikic's remark above. ### #127979: unreachable!("state is never set to invalid values") is reached Link: <https://github.com/rust-lang/rust/issues/127979> Creation date: 2024-07-19 Labels: `A-linkage`, `C-bug`, `C-optimization`, `I-unsound`, `O-windows`, `P-high`, `S-has-mcve`, `T-compiler`, `regression-from-stable-to-stable` Author: `janhohenheim` Working groups: Assignees: Pre-triage notes: - [Apply dllimport in ThinLTO #122790](https://github.com/rust-lang/rust/pull/122790) partially reverts [Fix Access Violation when using lld & ThinLTO on windows-msvc #103353](https://github.com/rust-lang/rust/pull/103353) which seems to fix the MCVE reported on the issue. - Fix PR is currently waiting on wesleyweiser's review. Pre-triage recommendation: - Assign issue to the fix PR author Zoxc. ### #127318: Wasm32 miscompilation when using u128 with multivalue and optimizations Link: <https://github.com/rust-lang/rust/issues/127318> Creation date: 2024-07-04 Labels: `A-LLVM`, `C-bug`, `I-miscompile`, `I-unsound`, `O-wasm`, `P-high`, `T-compiler` Author: `arriven` Working groups: Assignees: Pre-triage notes: - LLVM upstream wasm `multivalue` miscompile, upstream bug [Miscompile with multivalue ABI #98323](https://github.com/llvm/llvm-project/issues/98323) - AFAICT this needs to be fixed upstream and not much we can do in rustc outside of "tell users to not use u128 with `multivalue`" Pre-triage action: - `C-bug` -> `C-external-bug` Pre-triage remarks (update): - Probably dual-tag as `C-bug` and `C-externa-bug`, because even if fixed upstream I think we'll want some kind of assembly test on our end. ### #126747: Undefined behavior from stack overflow on wasm32 targets Link: <https://github.com/rust-lang/rust/issues/126747> Creation date: 2024-06-20 Labels: `C-bug`, `I-unsound`, `O-wasm`, `P-high`, `T-compiler` Author: `adambratschikaye` Working groups: Assignees: Pre-triage notes: - cc zulip prio discussion: <https://rust-lang.zulipchat.com/#narrow/channel/245100-t-compiler.2Fwg-prioritization.2Falerts/topic/.23126747.20Undefined.20behavior.20from.20stack.20overflow.20on.20wasm32.20ta.E2.80.A6> - AFAICT this is a hard problem in the general case (multi-threaded wasm) because *see bjorn3's comment below* - Possibly still some value for single-thread wasm code - cc Jubilee and bjorn3 who might know a bit about this See [bjorn3's comment](https://github.com/rust-lang/rust/issues/126747#issuecomment-2182374481): > On wasm stack guards like we use on native platforms are not possible. This also means stack probing is not possible either. The only option to detect stack overflows is thus checking the stack pointer against a per-thread limit corresponding to the lowest address of the stack. This is both slow, and the tooling convention for thread support doesn't provide this limit to threads, so we did have to default to not checking for stack overflows and give the user the option to set the stack limit for the current thread to avoid breaking backward compatibility with existing code. Pre-triage action: - Added `E-needs-design` label. Pre-triage recommendation: - Not very actionable, no concrete design yet, recommend to downgrade to P-low or even P-none. ### #125033: `-C target_cpu=cortex-a72` (and `-target-cpu=native` on Raspberry Pi) wrongly enables crypto features that are optional on Cortex-A72 Link: <https://github.com/rust-lang/rust/issues/125033> Creation date: 2024-05-12 Labels: `A-LLVM`, `A-target-feature`, `A-targets`, `C-bug`, `I-miscompile`, `I-unsound`, `O-AArch64`, `P-high`, `T-compiler`, `llvm-fixed-upstream` Author: `briansmith` Working groups: Assignees: Pre-triage notes: - Affects Tier 1 target `aarch64-unknown-linux-gnu` but for Raspberry Pi users(?) w/ `RUSTLFAGS=-target-cpu=native`. - LLVM upstream not very interested in changing target CPU definitions for backcompat: <https://github.com/llvm/llvm-project/issues/90365>. - "The `-C target-cpu=native` behavior was a plain bug. The `-C target-cpu=cortext-a72` behavior is just a difference in opinion.", cf. <https://github.com/rust-lang/rust/issues/125033#issuecomment-2394527115>. - Seems to be part of a more general problem with "`-mcpu=..` enables the maximum optional features for the cpu. They can be disabled with `+noxyz`." being maximal + opt-out versus minimal + opt-in. - See also [Jubilee's comment on LLVM](https://github.com/llvm/llvm-project/issues/113008#issuecomment-2465832819). - Possibly knowledgeable people to consult: nikic, Jubilee, ARM target maintainers, WG-embedded - Original issue status not very clear to me, maybe `E-needs-design` to see how to address `-C target_cpu=cortex-a72` enabling optional features? - No assignee. - P-level unclear. - Jubilee: I believe this is scheduled for the Dec 13 compiler meeting? https://github.com/rust-lang/calendar/blob/be02a523b5ae834381655950b5db3d40922bd58f/compiler.events-only.toml#L87-L96 ### #123733: `RUST_BACKTRACE=full` loop with `-Cpanic=abort` on `aarch64-unknown-linux-gnu` Link: <https://github.com/rust-lang/rust/issues/123733> Creation date: 2024-04-10 Labels: `A-runtime`, `C-bug`, `O-AArch64`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `cuviper` Working groups: Assignees: Pre-triage notes: - There was a candidate workaround PR <https://github.com/rust-lang/rust/pull/125844> but closed due to inactivity because PR author could not figure out how to add a regression test for it. - "E.g. a regression test for a specific platform, in which you need to run a sample binary with qemu or another emulator" - Not sure what test is needed here, didn't look too closely - Workaround PR tries to "add the UWTable attribute to every function with a personality function". - I don't understand the root cause well enough, but: - See [Amanieu's comment](https://github.com/rust-lang/rust/issues/123733#issuecomment-2054040339): - root cause "is because LLVM is clobbering the link register on the tail call". - "so the unwinder is behaving correctly, it's just that LLVM is emitting incorrect unwind info (or that it should be preserving the caller's link register" - [Two possible fixes proposed](https://github.com/rust-lang/rust/issues/123733#issuecomment-2054057666): - Figure out why rustc is adding a personality to this function and stop doing that. - Change LLVM so that that attaching a personality to a function implies the uwtable attribute. - Possibly knowledgeable people to consult: Amanieu, chrisd, Jubilee, nikic Pre-triage actions: - Added `A-backtrace` label. ### #122294: f64::round doesn't work properly on arm-unknown-linux-gnueabi Link: <https://github.com/rust-lang/rust/issues/122294> Creation date: 2024-03-10 Labels: `A-LLVM`, `C-bug`, `I-miscompile`, `I-unsound`, `O-Arm`, `P-high`, `T-compiler` Author: `vklachkov` Working groups: Assignees: Pre-triage notes: - `arm-unknown-linux-gnueabi` is a [Tier 2 w/ Host Tools target](https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-2-with-host-tools) but has no platform support page nor explicit target maintainers. - `f64::round` seems to be the problem but unclear to me from the issue if rustc is miscompiling or if it's a LLVM target backend problem - Seems to need more investigation. Pre-triage action: - Added `E-needs-investigation` label. ### #121638: ICE: rustfmt: `silent emitter attempted to translate a diagnostic` Link: <https://github.com/rust-lang/rust/issues/121638> Creation date: 2024-02-26 Labels: `A-rustfmt`, `C-bug`, `I-ICE`, `P-high`, `S-has-mcve`, `T-compiler` Author: `matthiaskrgr` Working groups: Assignees: Pre-triage notes: - Fixed by https://github.com/rust-lang/rust/pull/121487. Pre-triage actions: - Checked MCVE locally, closed as fixed. ### #121124: rust-1.75.0 fails to compile with ICE on aarch64 and various ppc arches with LTO enabled - error: could not compile memchr Link: <https://github.com/rust-lang/rust/issues/121124> Creation date: 2024-02-15 Labels: `A-LLVM`, `A-LTO`, `C-bug`, `I-ICE`, `I-unsound`, `O-AArch64`, `O-PowerPC`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `bowlofeggs` Working groups: Assignees: Pre-triage notes: - Miscompile with fat LTO? - But then also report of thin LTO fails on RISC-V, where fat LTO succeeds. - pnkfelix indicated they wanted to take a look this May but probably busy. - Lacks a MCVE (example was building rustc itself), hard to diagnose. Status unclear. Pre-triage actions: - Added `E-needs-mcve` and `E-needs-investigation`. ### #118223: x86-64 assembler silently truncates 64-bit address Link: <https://github.com/rust-lang/rust/issues/118223> Creation date: 2023-11-24 Labels: `A-LLVM`, `A-inline-assembly`, `C-bug`, `I-miscompile`, `I-unsound`, `O-x86_64`, `P-high`, `T-compiler` Author: `MauriceKayser` Working groups: Assignees: Pre-triage notes: - LLVM's inline assembly silently truncates 64-bit address due to Intel syntax vs AT&T Syntax(?) - Upstream bug report: [.intel_syntax should respect mov with 64-bit address #73481](https://github.com/llvm/llvm-project/issues/73481) - ... but upstream seems to consider this Not A Bug:tm: due to [some technicality](https://github.com/llvm/llvm-project/issues/73481#issuecomment-1831590174 - No idea what to do here - cc Jubilee who might know more - Jubilee: `movabs` is not an instruction in the Intel Software Development Manual, there is only `mov` (and given https://github.com/xoreaxeaxeax/movfuscator exists, mov is all you need). It's probably(?) a simple fix though if we dig through the assembler code. ### #118099: Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message Link: <https://github.com/rust-lang/rust/issues/118099> Creation date: 2023-11-20 Labels: `A-LLVM`, `C-bug`, `O-PowerPC`, `O-netbsd`, `P-high`, `T-compiler` Author: `he32` Working groups: Assignees: Pre-triage notes: - I'm clueless about this one. ### #117101: Errors compiling `libc` using rust 1.73.0 on `riscv64/ubuntu:focal` docker image - works with 1.72.1 Link: <https://github.com/rust-lang/rust/issues/117101> Creation date: 2023-10-23 Labels: `A-linkage`, `C-bug`, `O-riscv`, `P-high`, `T-compiler`, `regression-from-stable-to-stable`, `regression-untriaged` Author: `emlowe` Working groups: Assignees: Pre-triage notes: - Issue with specific `ld` version vs LLVM 17 bump. - Jubilee pinged target maintainers but no response so far. Pre-triage recommendation: - Close as inactive but recommend reopen with specific updated reproduction if still an issue. ### #116573: Inlining causes miscompilation of code that mixes target features Link: <https://github.com/rust-lang/rust/issues/116573> Creation date: 2023-10-09 Labels: `A-LLVM`, `A-codegen`, `A-target-feature`, `C-bug`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler` Author: `RalfJung` Working groups: Assignees: Pre-triage notes: - `-C target-feature` and multi-crates -- I think this is another specific instance of the general problem of mixing code compiled with different target features? - Unclear if still a way to "mix code from crates compiled with and without `-Ctarget-feature` to cause a problem?" - Pinged nikic and comex, no response yet. - cc RalfJung who reported the issue. - Current status unclear. ### #116344: The ABI of float types can be changed by `-Ctarget-feature` Link: <https://github.com/rust-lang/rust/issues/116344> Creation date: 2023-10-02 Labels: `A-ABI`, `A-floating-point`, `A-target-feature`, `I-unsound`, `P-high`, `T-compiler`, `T-opsem` Author: `RalfJung` Working groups: Assignees: Pre-triage notes: - This is a tracking issue. - General class of problems related to `-C` flags being able to change ABI, cc <https://github.com/rust-lang/rust/issues/131837>. - cc <https://github.com/rust-lang/rust/issues/131058> - Still needs investigation. ### #115465: Multiple nested loops taking very long to compile with CPU extensions Link: <https://github.com/rust-lang/rust/issues/115465> Creation date: 2023-09-02 Labels: `A-LLVM`, `C-bug`, `I-compiletime`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `Ben-Lichtman` Working groups: Assignees: Pre-triage notes: - Seems like something about LLVM 15 bump and specific to certain `target-cpu`s? - No *specific* bisection due to CI artifacts expiring, but no obvious candidates otherwise. - Probably needs expert LLVM investigations. ### #115336: `extern "C" fn` on sparc64 targets does not respect repr(transparent) Link: <https://github.com/rust-lang/rust/issues/115336> Creation date: 2023-08-29 Labels: `A-ABI`, `A-FFI`, `I-unsound`, `O-SPARC`, `P-high`, `T-compiler` Author: `RalfJung` Working groups: Assignees: Pre-triage notes: - One affected sparc64 target `sparc64-unknown-linux-gnu` is [Tier 2 w/out host tools](https://doc.rust-lang.org/nightly/rustc/platform-support.html?highlight=sparc#tier-2-without-host-tools). - `sparc64-unknown-linux-gnu` has no specific platform support page nor specific target maintainers. - No assignees. ### #115216: OOM/surprising memory consumption with Rust 1.72 Link: <https://github.com/rust-lang/rust/issues/115216> Creation date: 2023-08-25 Labels: `A-LLVM`, `C-bug`, `I-compilemem`, `O-wasm`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `amiyatulu` Working groups: Assignees: Pre-triage notes: - *Possibly* related to LLVM bug <https://github.com/llvm/llvm-project/issues/47793>. - Looks like an LLVM issue but no specific upstream issue filed. - Might need more investigation? ### #114858: ICE: unexpected initial operand type. Link: <https://github.com/rust-lang/rust/issues/114858> Creation date: 2023-08-15 Labels: `C-bug`, `F-impl_trait_in_assoc_type`, `I-ICE`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `fakeshadow` Working groups: Assignees: Pre-triage notes: - "underlying issue seems to be, these two types should be same after erasing their regions but even after erasing them, their upvars are different which shouldn't be." - <https://github.com/rust-lang/rust/pull/115215> downgrades assert in codegen to `warn!` but this just papers over *some* kind of genuine inconsistency. - Maybe cc lcnr and compiler-errors? - <https://github.com/rust-lang/rust/issues/126123> might be a duplicate for this but I can't say for certain. - No assignees. ### #114838: CI accepted doctests that do not build (due to missing feature gates) Link: <https://github.com/rust-lang/rust/issues/114838> Creation date: 2023-08-15 Labels: `P-high`, `T-compiler` Author: `RalfJung` Working groups: Assignees: Pre-triage notes: - Possibly [Allow unstable items to be re-exported unstably without requiring the feature be enabled #97301](https://github.com/rust-lang/rust/pull/97301) unintentionally also taking effect when `-Zforce-unstable-if-unmarked` is enabled. See [discussion](https://github.com/rust-lang/rust/pull/97301#issuecomment-1692823552). - cc petrochenkov and RalfJung maybe? Pre-triage actions: - Added missing `C-bug` and `A-stability` labels. ### #113104: Linking error on Rust 1.70 aarch64-unknown-linux-musl toolchain Link: <https://github.com/rust-lang/rust/issues/113104> Creation date: 2023-06-27 Labels: `A-linkage`, `C-bug`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `geauxvirtual` Working groups: Assignees: Pre-triage notes: - Linker shenanigans. I can't figure out the current status of this issue. Saethlin's MCVE of the *original* issue (I think?) was fixed and there's a fix for the `ring` problem (<https://github.com/briansmith/ring/issues/1808>) which seems to address the *original* reported problem. - However I think Saethlin's `deno-arm64` reproducer is still not fixed (I didn't have time to run the docker reproducer). Pre-triage recommendations: - Call for participation to check of `deno-arm64` reproducer is still problematic with latest rustc toolchain. - If still a problem, close *this* issue and open a new one for the `deno-arm64` reproducer. ### #103762: Broken compilation with `&(dyn Trait + '_)` Link: <https://github.com/rust-lang/rust/issues/103762> Creation date: 2022-10-30 Labels: `A-lifetimes`, `A-resolve`, `C-bug`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `Cerber-Ursi` Working groups: Assignees: Pre-triage notes: - Candidate fix PR closed due to inactivity. - cjgillot suggested "The fix is actually much simpler than all this: ignore the lifetime from the trait object when looking for elision candidates" in <https://github.com/rust-lang/rust/pull/104272#issuecomment-1328204307>. Pre-triage actions: - Unassigned original assignee due to closed PR and inactivity. ### #85099: A `Pin` unsoundness involving an `impl DerefMut for Pin<&dyn LocalTrait>` Link: <https://github.com/rust-lang/rust/issues/85099> Creation date: 2021-05-09 Labels: `A-pin`, `C-bug`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-lang`, `T-libs-api`, `T-types` Author: `steffahn` Working groups: Assignees: Pre-triage notes: - Tracked by T-types. ### #84591: HRTB on subtrait unsoundly provides HTRB on supertrait with weaker implied bounds Link: <https://github.com/rust-lang/rust/issues/84591> Creation date: 2021-04-26 Labels: `A-higher-ranked`, `A-implied-bounds`, `A-lifetimes`, `A-traits`, `A-typesystem`, `C-bug`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-types` Author: `steffahn` Working groups: Assignees: Pre-triage notes: - Tracked by T-types. ### #84366: 'static closures/FnDefs/futures with non-'static return type are unsound Link: <https://github.com/rust-lang/rust/issues/84366> Creation date: 2021-04-20 Labels: `A-associated-items`, `A-async-await`, `A-closures`, `A-lifetimes`, `A-traits`, `A-typesystem`, `AsyncAwait-Triaged`, `C-bug`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-lang`, `T-types` Author: `steffahn` Working groups: Assignees: Pre-triage notes: - Tracked by T-types. ### #79590: internal compiler error when inferring `_` type for Associated Type bound Link: <https://github.com/rust-lang/rust/issues/79590> Creation date: 2020-12-01 Labels: `A-associated-items`, `A-trait-objects`, `C-bug`, `I-ICE`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-types`, `glacier`, `regression-from-stable-to-stable` Author: `woodsmur` Working groups: Assignees: Pre-triage notes: - Has a glaicer (now crashes) test. - compiler-error self-assigned this last but unassigned, current status unclear. Maybe cc compiler-errors? - Unsure current status. ### #61275: Varargs are completely unchecked if passed as generics Link: <https://github.com/rust-lang/rust/issues/61275> Creation date: 2019-05-28 Labels: `A-FFI`, `I-miscompile`, `I-unsound`, `P-high`, `S-has-mcve`, `T-compiler` Author: `joshuabogue` Working groups: Assignees: Pre-triage notes: - cc [Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust #44930](https://github.com/rust-lang/rust/issues/44930) - AFAICT this is a breaking change but should at least warn/lint on cc [Jubilee's comment](https://github.com/rust-lang/rust/issues/44930#issuecomment-2198782794) due to C type promotion/demotion rules when interfacing with Rust? I don't fully understand the implication here. - See [Jubilee's comment](https://github.com/rust-lang/rust/issues/61275#issuecomment-2193942535). - Maybe cc Jubilee and RalfJung for current status? - ~~No assignees.~~ Jubilee: assigning myself? I've figured out enough about how codegen works to implement the codegen-level fixed so we at least have no more miscompilation concerns, though it may still result in surprising behavior. ### #57893: Coherence can be bypassed by an indirect impl for a trait object Link: <https://github.com/rust-lang/rust/issues/57893> Creation date: 2019-01-25 Labels: `A-DSTs`, `A-traits`, `C-bug`, `I-ICE`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-lang`, `T-types` Author: `arielb1` Working groups: Assignees: - Tracked by T-types, recent related work by compiler-errors I think? ## P-high T-compiler issues with owner (WG or assignee) ### #132673: Hang after encountering overflow errors for huge types Link: <https://github.com/rust-lang/rust/issues/132673> Creation date: 2024-11-06 Labels: `A-diagnostics`, `C-bug`, `I-hang`, `P-high`, `S-has-mcve`, `T-compiler`, `regression-from-stable-to-stable` Author: `wxie7` Working groups: Assignees: `compiler-errors` Pre-triage notes: - Very recent and c-e self-assigned, nothing to do. ### #125670: ICE: mir build: scope: `index out of bounds: the len is 0 but the index is 0` Link: <https://github.com/rust-lang/rust/issues/125670> Creation date: 2024-05-28 Labels: `C-bug`, `E-needs-test`, `F-inline_const`, `I-ICE`, `P-high`, `S-has-mcve`, `T-compiler` Author: `matthiaskrgr` Working groups: Assignees: `oli-obk` Pre-triage notes (follow-up 2024-11-15): - Regression tests added today in [Add test cases for #125918 #133012](https://github.com/rust-lang/rust/pull/133012). - Issue closed! Pre-triage notes: - Root cause is fixed by [Revert: create const block bodies in typeck via query feeding #125918](https://github.com/rust-lang/rust/pull/125918) which included *an* example, but not all of the variations in <https://github.com/rust-lang/rust/issues/125670>. - Keeping the issue open and rebranded as `E-easy` `E-needs-test` for regression tests on the simple examples. Don't know if this is needed, feel free to close if this seems redundant. Pre-triage actions: - Unassigned oli who's on vacation. - Added `E-easy` to issue and left comment for regression tests. ### #111229: mutable_transmutes lint should catch transmutes from a type without interior mutability to one with Link: <https://github.com/rust-lang/rust/issues/111229> Creation date: 2023-05-05 Labels: `A-LLVM`, `C-bug`, `P-high`, `T-compiler` Author: `glandium` Working groups: Assignees: `ChayimFriedman2` Pre-triage notes: - Lint attempt PR [Lint against `&T` to `&mut T` and `&T` to `&UnsafeCell<T>` transmutes #118446](https://github.com/rust-lang/rust/pull/118446) closed as inactive. - The cases seem complicated and tricky. - Maybe cc PG-safe-transmute? Pre-triage actions: - Added `A-lints` label. - Unassigned original assignee due to inactivity. ### #110174: Floating point comparisons are miscompiled for signalling NaN inputs on AArch64 Link: <https://github.com/rust-lang/rust/issues/110174> Creation date: 2023-04-11 Labels: `A-LLVM`, `A-floating-point`, `C-bug`, `I-miscompile`, `I-unsound`, `O-AArch64`, `P-high`, `T-compiler`, `WG-llvm`, `regression-from-stable-to-stable` Author: `thomcc` Working groups: `WG-llvm` Assignees: Pre-triage notes: - Seems to be an upstream LLVM bug but no linked LLVM issue. - Candidate LLVM PR [\[SDAG\] Drop select -> fmax/min folding in SelectionDAGBuilder #93575](https://github.com/llvm/llvm-project/pull/93575) might fix the underlying issue. Pre-triage actions: - `C-bug` -> `C-external-bug`: I don't think there's much to do on rustc's side atm, need upstream fix. ### #109114: `-Zdylib-lto` with ThinLTO is broken on windows-msvc Link: <https://github.com/rust-lang/rust/issues/109114> Creation date: 2023-03-14 Labels: `A-LLVM`, `A-LTO`, `I-miscompile`, `I-unsound`, `O-windows-msvc`, `P-high`, `T-compiler`, `WG-llvm`, `requires-nightly` Author: `Noratrieb` Working groups: `WG-llvm` Assignees: Pre-triage notes: - `dllimport` on Windows is Complicated:tm: - "difference in how dllimport is handled between lld-link.exe & link.exe" (see [comment](https://github.com/rust-lang/rust/issues/109114#issuecomment-1897074420)) - Reverting [Fix Access Violation when using lld & ThinLTO on windows-msvc #103353](https://github.com/rust-lang/rust/pull/103353) fixes *this* issue but most likely regresses the original thing #103353 was trying to fix. - cc [Apply dllimport in ThinLTO #122790](https://github.com/rust-lang/rust/pull/122790) again. - See also [Correctly handle dllimport on Windows #27438](https://github.com/rust-lang/rust/issues/27438). - Just Hard:tm: ### #108216: miscompilation with incremental + unpacked debug + macos Link: <https://github.com/rust-lang/rust/issues/108216> Creation date: 2023-02-18 Labels: `A-incr-comp`, `C-bug`, `I-unsound`, `O-macos`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `ehuss` Working groups: Assignees: `lqd` Pre-triage notes: - Assigned to lqd; no recent activity (presumably busy and hard to fix). - macOS incremental + unpacked debuginfo bug ### #107975: Miscompilation: Equal pointers comparing as unequal Link: <https://github.com/rust-lang/rust/issues/107975> Creation date: 2023-02-13 Labels: `A-LLVM`, `C-bug`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler`, `WG-llvm` Author: `JakobDegen` Working groups: `WG-llvm` Assignees: Pre-triage notes: - Very hard to fix upstream LLVM bug: [incorrect transformation around icmp: unclear semantics of "lifetime" intrinsics leads to miscompilation #45725](https://github.com/llvm/llvm-project/issues/45725) - See [Ralf's comment](https://github.com/rust-lang/rust/issues/107975#issuecomment-1771116608) below: > It's a very hard to fix bug in LLVM boiling down to different parts of LLVM making contradicting assumptions about the semantics of lifetime intrinsics, fundamentally caused by never properly deciding and documenting the semantics of said intrinsics. - [nikic tried to fix this but it turned out very difficult](https://github.com/rust-lang/rust/issues/107975#issuecomment-1439817961). Pre-triage actions: - `C-bug` -> `C-external-bug` Pre-triage remarks (update): - Probably dual tag as `C-bug` and `C-external-bug` as I imagine we'll want an assembly test once this is fixed, if this ever gets fixed? ### #102754: ld64.lld: error: too many personalities (4) for compact unwind to encode Link: <https://github.com/rust-lang/rust/issues/102754> Creation date: 2022-10-06 Labels: `A-linkage`, `C-bug`, `O-ios`, `O-macos`, `P-high`, `T-compiler`, `regression-from-stable-to-stable`, `relnotes` Author: `glandium` Working groups: Assignees: `pnkfelix` Pre-triage notes: - Assigned to pnkfelix, no recent activity. - Mixing ObjC, C++ and Rust in the same binary on aarch64-apple-darwin targets. - "It doesn't happen with ld64" ([comment](https://github.com/rust-lang/rust/issues/102754#issuecomment-1273849629)) - There was an LLVM fix for lld <https://reviews.llvm.org/D135728> - "`rust_eh_personality` will also be used in case of `-Cpanic=abort` for catching and aborting on exceptions crossing an `extern "C-unwind"` boundary in the future." (see [bjorn3's comment](https://github.com/rust-lang/rust/issues/102754#issuecomment-1293670608)) - "root of the problem is that `_rust_eh_personality` no longer gets stripped when using `-Clto` starting in 1.60 and so we still end up with too many in the final binary" ([comment](https://github.com/rust-lang/rust/issues/102754#issuecomment-1397613280)) - "Apple's compact unwinding format only allows a maximum of 3 personality functions." ([Amanieu's comment](https://github.com/rust-lang/rust/issues/102754#issuecomment-1399516695)) - "Ultimately, this is an Apple ABI issue, but I don't know whether that'll ever be fixed. They only allow 3 personalities to be used in `compact-unwind` in a single shared-object. And the system already has 3 canonical personalities already (`__gxx_personality_v0`, `__gcc_personality_v0`, and `__objc_personality_v0`). So, anyone using a custom personality is already doing something really fragile." (see [this comment](https://github.com/rust-lang/rust/issues/102754#issuecomment-1447337199)) - Seems like good solution unclear. - However, someone reported there is a [mitigation after Xcode 15](https://github.com/rust-lang/rust/issues/102754#issuecomment-1709663055) - > "For anyone else coming to this issue when trying to build a project in Xcode, I believe it's fixed/mitigated in Xcode 15. Not sure if it's properly fixed in Xcode 15, but my project now builds when targeting `aarch64-apple-ios-sim`." - Regression (or change) from [Move EH personality functions to std #92845](https://github.com/rust-lang/rust/pull/92845) - Maybe cc bjorn3 and Amanieu? ### #102174: extern "C" functions don't generate the same IR definitions as clang on x86, causing problems with cross-language LTO Link: <https://github.com/rust-lang/rust/issues/102174> Creation date: 2022-09-23 Labels: `A-ABI`, `A-FFI`, `A-LLVM`, `C-bug`, `I-unsound`, `O-x86_32`, `P-high`, `T-compiler`, `WG-llvm`, `regression-untriaged` Author: `glandium` Working groups: `WG-llvm` Assignees: Pre-triage notes: - Our "C" ABI vs clang's "C" ABI - "So IMO a systematic fix requires xlang LTO to be more careful, and in particular xlang inlining needs to be able to actually handle these kinds of ABI mismatches." (see [Ralf's comment](https://github.com/rust-lang/rust/issues/102174#issuecomment-2138097206)) - This just seems like a Hard Problem:tm: due to cross-lang LTO and then having to match clang's C ABI? - cc [Audit ABI implementations in `rustc_target` (vs Clang). #65111](https://github.com/rust-lang/rust/issues/65111) - Maybe cc bjorn3, RalfJung and Jubilee ### #101346: Incorrect handling of lateout pairs in inline asm Link: <https://github.com/rust-lang/rust/issues/101346> Creation date: 2022-09-02 Labels: `A-LLVM`, `A-inline-assembly`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler`, `WG-none` Author: `newpavlov` Working groups: `WG-none` Assignees: `nikic` Pre-triage notes: - Assigned to nikic, no recent activity. - Still problematic upstream; LLVM bug [Incorrect handling of lateout pairs in inline asm #57550](https://github.com/llvm/llvm-project/issues/57550) - nikic said on the LLVM bug "LLVM incorrectly reuses register for a pair of lateouts if it can see that one of those does not get used later." ([nikic's comment](https://github.com/llvm/llvm-project/issues/57550#issuecomment-1236337922)) ### #101060: Codegen weirdness for `sum` of `count_ones` over an array Link: <https://github.com/rust-lang/rust/issues/101060> Creation date: 2022-08-26 Labels: `A-LLVM`, `A-autovectorization`, `A-codegen`, `C-bug`, `I-slow`, `O-x86_64`, `P-high`, `T-compiler`, `WG-llvm`, `regression-from-stable-to-stable` Author: `alion02` Working groups: `WG-llvm` Assignees: Pre-triage notes: - Upstream LLVM regression/change, LLVM bug [Unprofitable ctpop vectorization #57476](https://github.com/llvm/llvm-project/issues/57476) - FWIW, using the same godbolt configuration in the original reproducer, rust 1.82.0 seems to have returned to the original codegen. See <https://godbolt.org/z/5Yfej6bfb> vs the original reproducer <https://godbolt.org/z/G9fa4Y8T7>. This happened some time between 1.75.0 -> 1.76.0 - [nikic said this was still a problem with LLVM 17](https://github.com/rust-lang/rust/issues/101060#issuecomment-1677419437) but the codegen returned to "normal" in 1.76.0 which AFAIK is still LLVM 17 but maybe backports in [Update LLVM submodule #119802](https://github.com/rust-lang/rust/pull/119802) somehow fixed this...? Pre-triage question: - Maybe can close with an assembly regression test? ### #100914: LLVM miscompiles large stack allocations Link: <https://github.com/rust-lang/rust/issues/100914> Creation date: 2022-08-23 Labels: `A-LLVM`, `C-bug`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler`, `WG-llvm` Author: `Cl00e9ment` Working groups: `WG-llvm` Assignees: `wesleywiser` Pre-triage notes: - Assigned to wesleyweiser. - Wesley had a fix PR for this upstream in [\[LLVM\] \[X86\] Fix integer overflows in frame layout for huge frames #101840]() - But that PR was reverted cf. <https://github.com/llvm/llvm-project/pull/101840#issuecomment-2301454179> in <https://github.com/llvm/llvm-project/commit/768598bcc3528ff5c4cd2c8a9b74d023614e1a9e>. - Upstream LLVM PR will need to be relanded. ### #99256: Source of lifetime coercion is not reported starting in 1.63 Link: <https://github.com/rust-lang/rust/issues/99256> Creation date: 2022-07-14 Labels: `A-diagnostics`, `A-lifetimes`, `C-bug`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `mqudsi` Working groups: `WG-diagnostics` Assignees: Pre-triage notes: - Diagnostics quality regression, but "difficult to fix" (cf. [estebank's comment](https://github.com/rust-lang/rust/issues/99256#issuecomment-1371402201)) - > We need to investigate what E0521 is doing that diverges significantly from E0759. I suspect this won't be trivial to fix - No activity since last P-high review. - Tried example on playground, seems to be the same. ### #98746: libcompiler-builtins contains DWARF5 debuginfo in 1.62.0 Link: <https://github.com/rust-lang/rust/issues/98746> Creation date: 2022-07-01 Labels: `A-debuginfo`, `C-bug`, `E-needs-mcve`, `E-needs-test`, `P-high`, `T-compiler` Author: `glandium` Working groups: Assignees: `pnkfelix` Pre-triage notes: - Assigned to pnkfelix, no recent activity. - Current status unclear, suspect need some testing/investigation to see if still problematic. ### #95926: rustc 1.59/1.60 builds musl binaries that segfault, when compiling with musl-gcc wrappers, due to static-pie default Link: <https://github.com/rust-lang/rust/issues/95926> Creation date: 2022-04-11 Labels: `C-bug`, `E-help-wanted`, `E-mentor`, `O-musl`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `joshtriplett` Working groups: `WG-diagnostics` Assignees: Pre-triage notes: - See [previous P-high review discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bsteering.20meeting.5D.202022-11-11.20compiler-team.23559.20P-high.20III/near/309211504) - Has to do with musl and `static-pie` default but unlikely to change without an MCP, and reverting default change can be equally problematic AFAIK. - Recommended course of action was diagnostics "of the problematic combination of flags." (see [pnkfelix's comment](https://github.com/rust-lang/rust/issues/95926#issuecomment-1508655129)) ### #90256: Rustc passes syntactically invalid input to attribute macros Link: <https://github.com/rust-lang/rust/issues/90256> Creation date: 2021-10-25 Labels: `A-proc-macros`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `dtolnay` Working groups: `WG-diagnostics` Assignees: - This was supposedly handed off to `WG-diagnostics` for design consideration, cc estebank and compiler-errors but follow-up activity unclear, solution unclear. - cc [Error reporting from attribute macros regressed in 1.46.0 #76360](https://github.com/rust-lang/rust/issues/76360) - See [previous P-high review discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202023-04-14.20P-high.20review.20.20compiler-team.23590/near/349394195). ### #89626: Undefined reference to `getauxval` in function `init_have_lse_atomics` when compiling to nightly `aarch64-unknown-linux-musl` Link: <https://github.com/rust-lang/rust/issues/89626> Creation date: 2021-10-07 Labels: `C-bug`, `O-Arm`, `O-musl`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `XAMPPRocky` Working groups: Assignees: `pnkfelix` Pre-triage notes: - Assigned to pnkfelix. - A recent comment suggested <https://github.com/rust-lang/rust/commit/9ed0d11efbec18a1fa4155576a3bcb685676d23c> fixed the issue. - Commit is part of [Avoid adding builtin functions to symbols.o #118568](https://github.com/rust-lang/rust/pull/118568), looks plausible. - Follow-up discussions on that issue makes it very unclear if it's still a problem. Pre-triage recommendation: - Close as fixed for now, ask to reopen *separate* issues if still a problem instead of continuing on the original issue. It's hard to follow what's actually being reported because possibly different issues in one trench coat. ### #86712: Rust musl build segfaults on startup when linked with LLD 12 Link: <https://github.com/rust-lang/rust/issues/86712> Creation date: 2021-06-29 Labels: `A-linkage`, `C-bug`, `E-needs-mcve`, `E-needs-test`, `O-musl`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `rocallahan` Working groups: Assignees: `pnkfelix` Pre-triage notes: - Assigned to pnkfelix. - Seemingly fixed but needs an MCVE + regression test. ### #86172: Compile error: static lifetime not satisfied but it is Link: <https://github.com/rust-lang/rust/issues/86172> Creation date: 2021-06-09 Labels: `A-lifetimes`, `C-bug`, `P-high`, `T-compiler`, `WG-async`, `regression-from-stable-to-stable` Author: `Skepfyr` Working groups: `WG-async` Assignees: Pre-triage notes: - This was said to have been handed of to `WG-async`, status unclear, no recent updates. - Longstanding problem, see also [Async function leads to a "more general type" error #71723](https://github.com/rust-lang/rust/issues/71723) due to [Separate projection bounds and predicates #73905](https://github.com/rust-lang/rust/pull/73905) which is probably necessary. ### #84970: Unstable fingerprints tracking issue Link: <https://github.com/rust-lang/rust/issues/84970> Creation date: 2021-05-06 Labels: `A-incr-comp`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `Mark-Simulacrum` Working groups: Assignees: `pnkfelix` Pre-triage notes: - Assigned to pnkfelix but this is really a tracking issue. - Incremental comp, this is generally a hard problem. - Still open tracked incr-comp issues. - pnkfelix could definitely use some help to investigating if not solving the incr-comp issues, but incr-comp issues are notoriously hard to repro so... ### #84873: Compile time+memory regression between 1.49.0 and 1.50.0 Link: <https://github.com/rust-lang/rust/issues/84873> Creation date: 2021-05-03 Labels: `C-bug`, `I-compilemem`, `I-compiletime`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `olix0r` Working groups: Assignees: `pnkfelix` Pre-triage notes: - Assigned to pnkfelix, no recent activity. - lqd has done some investigation in <https://github.com/rust-lang/rust/issues/84873#issuecomment-1320995012>. - Not sure how actionable this is: "I think the main task that remains is for someone on our team to go back and check how the newer versions of the compiler behave on the old versions of linkerd, prior to when they put all the extra boxes in to work around this issue." ([pnkfelix's comment](https://github.com/rust-lang/rust/issues/84873#issuecomment-1320214001)) - cc [previous P-high review discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202022-11-18.20planning.20.2B.20compiler-team.23559.20P-high.20IV/near/310852382). ### #83060: Regressions with large (2-4GB) stack arrays on large stacks Link: <https://github.com/rust-lang/rust/issues/83060> Creation date: 2021-03-12 Labels: `A-LLVM`, `A-array`, `C-bug`, `E-help-wanted`, `E-medium`, `E-mentor`, `I-unsound`, `P-high`, `T-compiler`, `WG-diagnostics`, `WG-llvm` Author: `joshtriplett` Working groups: `WG-diagnostics`, `WG-llvm` Assignees: `iSwapna`, `wesleywiser` - Wesley has an upstream LLVM PR [\[LLVM\] \[X86\] Fix integer overflows in frame layout for huge frames #101840] but it was reverted due to hitting an assertion. - This is the same upstream LLVM PR linked as [#100914: LLVM miscompiles large stack allocations](https://github.com/rust-lang/rust/issues/100914). - LLVM PR will need to reland then a rustc side follow-up? ### #81317: Type can no longer be inferred in 1.49 Link: <https://github.com/rust-lang/rust/issues/81317> Creation date: 2021-01-24 Labels: `A-inference`, `P-high`, `T-compiler`, `T-types`, `regression-from-stable-to-stable` Author: `Skgland` Working groups: Assignees: `oli-obk` Pre-triage notes: - Assigned to oli who is currently on vacation. - Consequence of [Separate projection bounds and predicates #73905](https://github.com/rust-lang/rust/pull/73905) which I *think* is necessary. - cc [#86172: Compile error: static lifetime not satisfied but it is](https://github.com/rust-lang/rust/issues/86172) ### #79609: Passing `-C panic=abort` still attempts to link in `libunwind` when targeting `i686-pc-windows-gnu` on `v1.44+` Link: <https://github.com/rust-lang/rust/issues/79609> Creation date: 2020-12-01 Labels: `A-cross`, `A-linkage`, `A-runtime`, `C-bug`, `ICEBreaker-Cleanup-Crew`, `O-x86_32`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `staticfloat` Working groups: Assignees: `wesleywiser` - Assigned to wesleywiser, no recent activity. - `i686-pc-windows-gnu` is a [Tier 1 target](https://doc.rust-lang.org/nightly/rustc/platform-support.html?highlight=i686-pc-windows-gnu#tier-1-with-host-tools). - "it seems like finding a seamless solution to this problem is either hard or impossible." ([pnkfelix's comment](https://github.com/rust-lang/rust/issues/79609#issuecomment-1335471030)) because - Recommendation is to just document this as a platform quirk (see [pnkfelix's comment](https://github.com/rust-lang/rust/issues/79609#issuecomment-1453722325)). ### #76360: Error reporting from attribute macros regressed in 1.46.0 Link: <https://github.com/rust-lang/rust/issues/76360> Creation date: 2020-09-05 Labels: `A-diagnostics`, `A-proc-macros`, `ICEBreaker-Cleanup-Crew`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `ahl` Working groups: `WG-diagnostics` Assignees: `estebank` Pre-triage notes: - Handed off to `WG-diagnostics` and estebank self-assigned, no recent activity (this looks hard). - Consequence of [expand: Stop using nonterminals for passing tokens to attribute and derive macros #73345](https://github.com/rust-lang/rust/pull/73345). ### #75385: Link fails with actix-web when using GNU linker's default linker script Link: <https://github.com/rust-lang/rust/issues/75385> Creation date: 2020-08-11 Labels: `A-linkage`, `C-bug`, `O-linux`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `rocallahan` Working groups: Assignees: `wesleywiser` Pre-triage notes: - Current status unclear, wesleywiser self-assigned, no recent activity. Pre-triage recommendation: - Ask issue reporter if this is still a problem *today* (the bug was reported a *while* ago). - Unassign Wesley. ### #72837: Compiling simple (but long) code with lots of `async`/`await` takes hours Link: <https://github.com/rust-lang/rust/issues/72837> Creation date: 2020-05-31 Labels: `A-async-await`, `AsyncAwait-Triaged`, `C-bug`, `I-compilemem`, `I-compiletime`, `P-high`, `T-compiler`, `WG-async` Author: `Yoric` Working groups: `WG-async` Assignees: Pre-triage notes: - This *was* tagged `WG-async` but current status unclear, no assignees, no recent activity. Pre-triage recommendation: - Ask `WG-async` if they're still tracking this issue or what the status is. ### #70819: `forbid` overwritten by later `allow` on the same "scope level" Link: <https://github.com/rust-lang/rust/issues/70819> Creation date: 2020-04-05 Labels: `A-frontend`, `A-lint`, `C-bug`, `ICEBreaker-Cleanup-Crew`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `RalfJung` Working groups: `WG-diagnostics` Assignees: `pnkfelix` Pre-triage notes: - The *specific* issue about in-source `forbid` lint level annotations was fixed, but the cli arg order lint level flags have a different issue. Pre-triage remark: - Our lint level calculation is extremely complex and underspecified (T-compiler wise and T-lang wise alike), cf. <https://github.com/rust-lang/rustc-dev-guide/issues/1168#issuecomment-2453033959> and <https://github.com/rust-lang/rust/pull/113307#issuecomment-1726329956>. Pre-triage recommendation: - Unassign pnkfelix, not further actionable atm. - Close this issue and open a fresh one about CLI forbid lint level flags. ### #70143: Locals aligned to greater than page size can cause unsound behavior Link: <https://github.com/rust-lang/rust/issues/70143> Creation date: 2020-03-19 Labels: `A-LLVM`, `C-bug`, `I-unsound`, `ICEBreaker-LLVM`, `O-windows`, `P-high`, `T-compiler` Author: `retep998` Working groups: Assignees: `cuviper` Pre-triage notes: - Assigned to cuviper but mostly for keeping track of status. - Still needs someone to implement a fix, unclear to me at present what that actually is, may need further investigation. ### #70022: Statics don't support alignments larger than the page size Link: <https://github.com/rust-lang/rust/issues/70022> Creation date: 2020-03-15 Labels: `C-bug`, `I-unsound`, `O-linux`, `O-windows-gnu`, `O-windows-msvc`, `P-high`, `T-compiler` Author: `Amanieu` Working groups: Assignees: `pnkfelix` Pre-triage notes: - Assigned to pnkfelix, no recent activity. - Don't really know much about this one. ### #67497: Switching to opt-level=z on i686-windows-msvc triggers STATUS_ACCESS_VIOLATION Link: <https://github.com/rust-lang/rust/issues/67497> Creation date: 2019-12-21 Labels: `A-LLVM`, `C-bug`, `E-needs-mcve`, `I-unsound`, `O-windows`, `O-x86_32`, `P-high`, `T-compiler` Author: `dignifiedquire` Working groups: Assignees: `wesleywiser` Pre-triage notes: - Assigned to wesleyweiser, current status unclear, no recent activity. - Seems to still need a MCVE. - Previous investigation appears to be a false lead, so still needs investigation. Pre-triage actions: - Added `E-needs-investigation` label. ### #66916: Emscripten builds broken on nightly? (Linking errors in fresh "hello world" crate) Link: <https://github.com/rust-lang/rust/issues/66916> Creation date: 2019-12-01 Labels: `A-linkage`, `C-bug`, `E-needs-mcve`, `O-emscripten`, `O-wasm`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `elidupree` Working groups: Assignees: `pnkfelix` Pre-triage notes: - `wasm32-unknown-emscripten` is a [Tier 2 target](https://doc.rust-lang.org/nightly/rustc/platform-support/wasm32-unknown-emscripten.html?highlight=wasm32-unknown-emscripten#wasm32-unknown-emscripten) - Assigned to pnkfelix, no recent activity, current status unknown. - Maybe cc target maintainers <https://github.com/hoodmane> and <https://github.com/juntyr> ### #65391: rust-lld since 1.38 overlaps .text with .rodata for embedded arm target Link: <https://github.com/rust-lang/rust/issues/65391> Creation date: 2019-10-13 Labels: `A-LLVM`, `A-linkage`, `C-bug`, `O-Arm`, `P-high`, `T-compiler`, `WG-embedded`, `regression-from-stable-to-stable` Author: `lightblu` Working groups: `WG-embedded` Assignees: `pnkfelix` Pre-triage notes: - Seems to have *probably* been fixed in lld, issue reporter [cannot repro original issue](https://github.com/rust-lang/rust/issues/65391#issuecomment-1465958049). Pre-triage actions: - Closed issue as fixed, otherwise inactionable. ### #64340: Linking issue with Rust 1.37.0 Link: <https://github.com/rust-lang/rust/issues/64340> Creation date: 2019-09-10 Labels: `A-linkage`, `C-bug`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `vitvakatu` Working groups: Assignees: `pnkfelix` Pre-triage notes: - This might be an upstream issue with `bindgen` cf. [pnkfelix's comment](https://github.com/rust-lang/rust/issues/64340#issuecomment-1355157400)? But not sure, it appears that the issue needs some more investigation. - Maybe cc pnkfelix as you might know more about this issue? - Possibly cc: - [dylib shared libraries will not make public symbols that may be necessary to link inlined code #65610](https://github.com/rust-lang/rust/issues/65610) - [As of 1.37.0, dylib shared libraries no longer support interpositioning of functions defined in C #66265](https://github.com/rust-lang/rust/issues/66265) Pre-triage actions: - Tagged as `E-needs-investigation` to determine if this is something *we* need to fix in rustc or if this is an upstream `bindgen` bug. - If `bindgen` bug, change `C-bug` -> `C-extern-bug` and probably downgrade to P-medium? ### #53934: disambiguate between multiple suggestions and a single multi-span suggestion; or, JSON error format is not round-trippable Link: <https://github.com/rust-lang/rust/issues/53934> Creation date: 2018-09-03 Labels: `A-diagnostics`, `C-cleanup`, `D-diagnostic-infra`, `E-medium`, `E-mentor`, `P-high`, `T-compiler`, `WG-diagnostics` Author: `zackmdavis` Working groups: `WG-diagnostics` Assignees: `yerke` Pre-triage notes: - This is a long-standing diagnostics json issue. - Need to consult with `WG-diagnostics` and especially estebank, clippy and cargo about diagnostics json output. - Needs design, and possibly versioning the diagnostics json format? - No recent activity. Pre-triage actions: - Unassigned yerke due to inactivity, no recent progress on this issue. ### #53014: LNK1189 "library limit of 65535 obj exceeded" building rustc Link: <https://github.com/rust-lang/rust/issues/53014> Creation date: 2018-08-03 Labels: `A-codegen`, `A-incr-comp`, `A-linkage`, `C-bug`, `E-help-wanted`, `O-windows-msvc`, `P-high`, `T-compiler`, `WG-incr-comp` Author: `scottmcm` Working groups: `WG-incr-comp` Assignees: `wesleywiser` Pre-triage notes: - Limit in msvc link.exe's number of modules (objs), large number of CGU can push it over the limit. - Assigned to wesleywiser, but current status unclear. - Fix upstream in msvc seems... unlikely at best. - [Recent report](https://github.com/rust-lang/rust/issues/53014#issuecomment-2298708853) that this is still an issue (as expected). - We're not the [only](https://github.com/JuliaLang/julia/issues/52561) [project](https://reviews.llvm.org/D86701) that runs into this. ### #47949: Panics in destructors can cause the return value to be leaked Link: <https://github.com/rust-lang/rust/issues/47949> Creation date: 2018-02-01 Labels: `A-destructors`, `C-enhancement`, `I-unsound`, `P-high`, `T-compiler`, `T-lang` Author: `arielb1` Working groups: Assignees: `matthewjasper` Pre-triage notes: - Assigned to matthewjasper, candidate PR [Fix leaks from panics in destructors #125923](https://github.com/rust-lang/rust/pull/125923) in progress. - However, there are some [unresolved concerns](https://github.com/rust-lang/rust/pull/125923#pullrequestreview-2237855136) by lcnr regarding the current code structure / approach in the PR. - Probably no need to do anything here. ### #25229: Pretty Printing on `*-windows-gnu` broken because .debug_gdb_scripts is not emitted Link: <https://github.com/rust-lang/rust/issues/25229> Creation date: 2015-05-09 Labels: `A-debuginfo`, `C-bug`, `O-windows-gnu`, `P-high`, `T-compiler`, `WG-debugging` Author: `chuckries` Working groups: `WG-debugging` Assignees: Pre-triage notes: - Could use some retesting to check current status. - Maybe [GNU linker](https://sourceware.org/bugzilla/show_bug.cgi?id=21459) bug but unlikely to be fixed any time soon.

    Import from clipboard

    Paste your markdown or webpage here...

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lose their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template has been removed or transferred.
    Upgrade
    All
    • All
    • Team
    No template.

    Create a template

    Upgrade

    Delete template

    Do you really want to delete this template?
    Turn this template into a regular note and keep its content, versions, and comments.

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
    Wallet ( )
    Connect another wallet

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Help & Tutorial

    How to use Book mode

    Slide Example

    API Docs

    Edit in VSCode

    Install browser extension

    Contacts

    Feedback

    Discord

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions and GitHub Sync
    Get Full History Access

    • Edit version name
    • Delete

    revision author avatar     named on  

    More Less

    Note content is identical to the latest version.
    Compare
      Choose a version
      No search result
      Version not found
    Sign in to link this note to GitHub
    Learn more
    This note is not linked with GitHub
     

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub
        • Please sign in to GitHub and install the HackMD app on your GitHub repo.
        • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
        Learn more  Sign in to GitHub

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Include title and tags
        Available push count

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully