Add `-Zno-jump-tables` #105812

ojeda · 2022-12-17T02:03:02Z

This flag mimics GCC/Clang's -fno-jump-tables [1][2], which makes the codegen backend avoid generating jump tables when lowering switches.

In the case of LLVM, the "no-jump-tables"="true" function attribute is added to every function.

The kernel currently needs it for x86 when enabling IBT [3], as well as for Alpha (plus VDSO objects in MIPS/LoongArch).

[1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-jump-tables
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fjump-tables
[3] https://github.com/torvalds/linux/blob/v6.1/arch/x86/Makefile#L75-L83

rustbot · 2022-12-17T02:03:13Z

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

TaKO8Ki · 2022-12-20T05:37:19Z

I want to reroll it. r? compiler

nikic · 2022-12-20T08:34:13Z

@bors r+

bors · 2022-12-20T08:34:16Z

📌 Commit 36125789c074ab9b1aadb4b5dc2099ca7db6a316 has been approved by nikic

It is now in the queue for this repository.

nikic · 2022-12-20T08:34:44Z

@bors rollup=never assembly test

bors · 2022-12-20T13:36:18Z

⌛ Testing commit 36125789c074ab9b1aadb4b5dc2099ca7db6a316 with merge abd27fd360c7c67efb43690a996aeeb591975264...

bors · 2022-12-20T13:58:02Z

💔 Test failed - checks-actions

src/test/codegen/no-jump-tables.rs

nikic · 2022-12-20T19:07:56Z

@bors r+

bors · 2022-12-20T19:07:58Z

📌 Commit 70c4ea0681859fe18a0c4106509aeceace357a1d has been approved by nikic

It is now in the queue for this repository.

bors · 2022-12-20T19:50:59Z

⌛ Testing commit 70c4ea0681859fe18a0c4106509aeceace357a1d with merge 4352f680ca9e476629bcdf9b758b575fb69ef918...

bors · 2022-12-21T04:23:05Z

⌛ Testing commit a65ec44 with merge 554eb669173b4e9a0ac5e011ac4408fc6bcec7a1...

bors · 2022-12-21T08:38:05Z

💥 Test timed out

rust-log-analyzer · 2022-12-21T14:18:13Z

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

nikic · 2022-12-21T15:53:43Z

@bors retry timeout in install awscli

ojeda · 2022-12-21T15:54:47Z

Thanks Nikita!

bors · 2022-12-21T17:38:41Z

⌛ Testing commit a65ec44 with merge a8207df...

bors · 2022-12-21T20:19:16Z

☀️ Test successful - checks-actions
Approved by: nikic
Pushing a8207df to master...

rust-timer · 2022-12-21T21:39:52Z

Finished benchmarking commit (a8207df): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

…s, r=wesleywiser Stabilize -Zno-jump-tables into -Cjump-tables=bool I propose stabilizing the -Zno-jump-tables option into -Cjump-tables=<bool>. # `-Zno-jump-tables` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC was created for this option. This was a narrowly scoped option introduced in rust-lang#105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows. The tracking is rust-lang#116592. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The behavior of this flag is well defined, and mimics the existing `-fno-jump-tables` option currently available with LLVM and GCC with some caveats: * Unlike clang or gcc, this option may be ignored by the code generation backend. Rust can support multiple code-generation backends. For stabilization, only the LLVM backend honors this option. * The usage of this option will not guarantee a library or binary is free of jump tables. To ensure a jump-table free binary, all crates in the build graph must be compiled with this option. This includes implicitly linked crates such as std or core. * This option only enforces the crate being compiled is free of jump tables. * No verification is done to ensure other crates are compiled with this option. Enforcing code generation options are applied across the crate graph is out of scope for this option. What should the flag name be? * As introduced, this option was named `-Zno-jump-tables`. However, other major toolchains allow both positive and negative variants of this option to toggle this feature. Renaming the option to `-Cjump-tables=<bool>` makes this option consistent, and if for some reason, expandable to other arguments in the future. Notably, many LLVM targets have a configurable and different thresholds for when to lower into a jump table. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No. This option is used exclusively to gate a very specific class of optimization. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) * The original PR rust-lang#105812 by `@ojeda` * The stabilized CLI option is parsed as a bool: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_session/src/options.rs#L2025-L2026 * This options adds an attribute to each llvm function via: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_codegen_llvm/src/attributes.rs#L210-L215 * Finally, the rustc book is updated with the new option: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/src/doc/rustc/src/codegen-options/index.md?plain=1#L212-L223 ## Has a call-for-testing period been conducted? If so, what feedback was received? No. The option has originally created is being used by Rust For Linux to build the x86-64 kernel without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? There are no outstanding issues. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization * `@ojeda` implemented this feature in rust-lang#105815 as `-Zno-jump-tables`. * `@tgross35` created and maintained the tracking issue rust-lang#116592, and provided feedback about the naming of the cli option. ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? There are none. ## What static checks are done that are needed to prevent undefined behavior? This option cannot cause undefined behavior. It is a boolean option with well defined behavior in both cases. ## In what way does this feature interact with the reference/specification, and are those edits prepared? This adds a new cli option to `rustc`. The documentation is updated, and the unstable documentation cleaned up in this PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? None. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support is required from other rust tooling. ## Open Items - [x] Are there objections renaming `-Zno-jump-tables` to `-Cjump-tables=<bool>`? The consensus is no. - [x] Is it desirable to keep `-Zno-jump-tables` for a period of time? The consensus is no. --- Closes rust-lang#116592

Rust 1.93.0 (expected 2026-01-22) is stabilizing `-Zno-jump-tables` [1][2] as `-Cjump-tables=n` [3]. Without this change, one would eventually see: RUSTC L rust/core.o error: unknown unstable option: `no-jump-tables` Thus support the upcoming version. Link: rust-lang/rust#116592 [1] Link: rust-lang/rust#105812 [2] Link: rust-lang/rust#145974 [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Rust 1.93.0 (expected 2026-01-22) is stabilizing `-Zno-jump-tables` [1][2] as `-Cjump-tables=n` [3]. Without this change, one would eventually see: RUSTC L rust/core.o error: unknown unstable option: `no-jump-tables` Thus support the upcoming version. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: rust-lang/rust#116592 [1] Link: rust-lang/rust#105812 [2] Link: rust-lang/rust#145974 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20251101094011.1024534-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

…s, r=wesleywiser Stabilize -Zno-jump-tables into -Cjump-tables=bool I propose stabilizing the -Zno-jump-tables option into -Cjump-tables=<bool>. # `-Zno-jump-tables` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC was created for this option. This was a narrowly scoped option introduced in rust-lang#105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows. The tracking is rust-lang#116592. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The behavior of this flag is well defined, and mimics the existing `-fno-jump-tables` option currently available with LLVM and GCC with some caveats: * Unlike clang or gcc, this option may be ignored by the code generation backend. Rust can support multiple code-generation backends. For stabilization, only the LLVM backend honors this option. * The usage of this option will not guarantee a library or binary is free of jump tables. To ensure a jump-table free binary, all crates in the build graph must be compiled with this option. This includes implicitly linked crates such as std or core. * This option only enforces the crate being compiled is free of jump tables. * No verification is done to ensure other crates are compiled with this option. Enforcing code generation options are applied across the crate graph is out of scope for this option. What should the flag name be? * As introduced, this option was named `-Zno-jump-tables`. However, other major toolchains allow both positive and negative variants of this option to toggle this feature. Renaming the option to `-Cjump-tables=<bool>` makes this option consistent, and if for some reason, expandable to other arguments in the future. Notably, many LLVM targets have a configurable and different thresholds for when to lower into a jump table. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No. This option is used exclusively to gate a very specific class of optimization. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) * The original PR rust-lang#105812 by `@ojeda` * The stabilized CLI option is parsed as a bool: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_session/src/options.rs#L2025-L2026 * This options adds an attribute to each llvm function via: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_codegen_llvm/src/attributes.rs#L210-L215 * Finally, the rustc book is updated with the new option: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/src/doc/rustc/src/codegen-options/index.md?plain=1#L212-L223 ## Has a call-for-testing period been conducted? If so, what feedback was received? No. The option has originally created is being used by Rust For Linux to build the x86-64 kernel without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? There are no outstanding issues. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization * `@ojeda` implemented this feature in rust-lang#105815 as `-Zno-jump-tables`. * `@tgross35` created and maintained the tracking issue rust-lang#116592, and provided feedback about the naming of the cli option. ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? There are none. ## What static checks are done that are needed to prevent undefined behavior? This option cannot cause undefined behavior. It is a boolean option with well defined behavior in both cases. ## In what way does this feature interact with the reference/specification, and are those edits prepared? This adds a new cli option to `rustc`. The documentation is updated, and the unstable documentation cleaned up in this PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? None. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support is required from other rust tooling. ## Open Items - [x] Are there objections renaming `-Zno-jump-tables` to `-Cjump-tables=<bool>`? The consensus is no. - [x] Is it desirable to keep `-Zno-jump-tables` for a period of time? The consensus is no. --- Closes rust-lang#116592

…s, r=wesleywiser Stabilize -Zno-jump-tables into -Cjump-tables=bool I propose stabilizing the -Zno-jump-tables option into -Cjump-tables=<bool>. # `-Zno-jump-tables` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC was created for this option. This was a narrowly scoped option introduced in rust-lang#105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows. The tracking is rust-lang#116592. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The behavior of this flag is well defined, and mimics the existing `-fno-jump-tables` option currently available with LLVM and GCC with some caveats: * Unlike clang or gcc, this option may be ignored by the code generation backend. Rust can support multiple code-generation backends. For stabilization, only the LLVM backend honors this option. * The usage of this option will not guarantee a library or binary is free of jump tables. To ensure a jump-table free binary, all crates in the build graph must be compiled with this option. This includes implicitly linked crates such as std or core. * This option only enforces the crate being compiled is free of jump tables. * No verification is done to ensure other crates are compiled with this option. Enforcing code generation options are applied across the crate graph is out of scope for this option. What should the flag name be? * As introduced, this option was named `-Zno-jump-tables`. However, other major toolchains allow both positive and negative variants of this option to toggle this feature. Renaming the option to `-Cjump-tables=<bool>` makes this option consistent, and if for some reason, expandable to other arguments in the future. Notably, many LLVM targets have a configurable and different thresholds for when to lower into a jump table. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No. This option is used exclusively to gate a very specific class of optimization. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) * The original PR rust-lang#105812 by ``@ojeda`` * The stabilized CLI option is parsed as a bool: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_session/src/options.rs#L2025-L2026 * This options adds an attribute to each llvm function via: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_codegen_llvm/src/attributes.rs#L210-L215 * Finally, the rustc book is updated with the new option: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/src/doc/rustc/src/codegen-options/index.md?plain=1#L212-L223 ## Has a call-for-testing period been conducted? If so, what feedback was received? No. The option has originally created is being used by Rust For Linux to build the x86-64 kernel without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? There are no outstanding issues. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization * ``@ojeda`` implemented this feature in rust-lang#105815 as `-Zno-jump-tables`. * ``@tgross35`` created and maintained the tracking issue rust-lang#116592, and provided feedback about the naming of the cli option. ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? There are none. ## What static checks are done that are needed to prevent undefined behavior? This option cannot cause undefined behavior. It is a boolean option with well defined behavior in both cases. ## In what way does this feature interact with the reference/specification, and are those edits prepared? This adds a new cli option to `rustc`. The documentation is updated, and the unstable documentation cleaned up in this PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? None. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support is required from other rust tooling. ## Open Items - [x] Are there objections renaming `-Zno-jump-tables` to `-Cjump-tables=<bool>`? The consensus is no. - [x] Is it desirable to keep `-Zno-jump-tables` for a period of time? The consensus is no. --- Closes rust-lang#116592

…s, r=wesleywiser Stabilize -Zno-jump-tables into -Cjump-tables=bool I propose stabilizing the -Zno-jump-tables option into -Cjump-tables=<bool>. # `-Zno-jump-tables` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC was created for this option. This was a narrowly scoped option introduced in rust-lang#105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows. The tracking is rust-lang#116592. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The behavior of this flag is well defined, and mimics the existing `-fno-jump-tables` option currently available with LLVM and GCC with some caveats: * Unlike clang or gcc, this option may be ignored by the code generation backend. Rust can support multiple code-generation backends. For stabilization, only the LLVM backend honors this option. * The usage of this option will not guarantee a library or binary is free of jump tables. To ensure a jump-table free binary, all crates in the build graph must be compiled with this option. This includes implicitly linked crates such as std or core. * This option only enforces the crate being compiled is free of jump tables. * No verification is done to ensure other crates are compiled with this option. Enforcing code generation options are applied across the crate graph is out of scope for this option. What should the flag name be? * As introduced, this option was named `-Zno-jump-tables`. However, other major toolchains allow both positive and negative variants of this option to toggle this feature. Renaming the option to `-Cjump-tables=<bool>` makes this option consistent, and if for some reason, expandable to other arguments in the future. Notably, many LLVM targets have a configurable and different thresholds for when to lower into a jump table. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No. This option is used exclusively to gate a very specific class of optimization. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) * The original PR rust-lang#105812 by ```@ojeda``` * The stabilized CLI option is parsed as a bool: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_session/src/options.rs#L2025-L2026 * This options adds an attribute to each llvm function via: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_codegen_llvm/src/attributes.rs#L210-L215 * Finally, the rustc book is updated with the new option: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/src/doc/rustc/src/codegen-options/index.md?plain=1#L212-L223 ## Has a call-for-testing period been conducted? If so, what feedback was received? No. The option has originally created is being used by Rust For Linux to build the x86-64 kernel without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? There are no outstanding issues. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization * ```@ojeda``` implemented this feature in rust-lang#105815 as `-Zno-jump-tables`. * ```@tgross35``` created and maintained the tracking issue rust-lang#116592, and provided feedback about the naming of the cli option. ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? There are none. ## What static checks are done that are needed to prevent undefined behavior? This option cannot cause undefined behavior. It is a boolean option with well defined behavior in both cases. ## In what way does this feature interact with the reference/specification, and are those edits prepared? This adds a new cli option to `rustc`. The documentation is updated, and the unstable documentation cleaned up in this PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? None. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support is required from other rust tooling. ## Open Items - [x] Are there objections renaming `-Zno-jump-tables` to `-Cjump-tables=<bool>`? The consensus is no. - [x] Is it desirable to keep `-Zno-jump-tables` for a period of time? The consensus is no. --- Closes rust-lang#116592

Rollup merge of #145974 - pmur:murp/stabilize-zno-jump-tables, r=wesleywiser Stabilize -Zno-jump-tables into -Cjump-tables=bool I propose stabilizing the -Zno-jump-tables option into -Cjump-tables=<bool>. # `-Zno-jump-tables` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC was created for this option. This was a narrowly scoped option introduced in #105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows. The tracking is #116592. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The behavior of this flag is well defined, and mimics the existing `-fno-jump-tables` option currently available with LLVM and GCC with some caveats: * Unlike clang or gcc, this option may be ignored by the code generation backend. Rust can support multiple code-generation backends. For stabilization, only the LLVM backend honors this option. * The usage of this option will not guarantee a library or binary is free of jump tables. To ensure a jump-table free binary, all crates in the build graph must be compiled with this option. This includes implicitly linked crates such as std or core. * This option only enforces the crate being compiled is free of jump tables. * No verification is done to ensure other crates are compiled with this option. Enforcing code generation options are applied across the crate graph is out of scope for this option. What should the flag name be? * As introduced, this option was named `-Zno-jump-tables`. However, other major toolchains allow both positive and negative variants of this option to toggle this feature. Renaming the option to `-Cjump-tables=<bool>` makes this option consistent, and if for some reason, expandable to other arguments in the future. Notably, many LLVM targets have a configurable and different thresholds for when to lower into a jump table. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No. This option is used exclusively to gate a very specific class of optimization. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) * The original PR #105812 by ```@ojeda``` * The stabilized CLI option is parsed as a bool: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_session/src/options.rs#L2025-L2026 * This options adds an attribute to each llvm function via: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_codegen_llvm/src/attributes.rs#L210-L215 * Finally, the rustc book is updated with the new option: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/src/doc/rustc/src/codegen-options/index.md?plain=1#L212-L223 ## Has a call-for-testing period been conducted? If so, what feedback was received? No. The option has originally created is being used by Rust For Linux to build the x86-64 kernel without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? There are no outstanding issues. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization * ```@ojeda``` implemented this feature in #105815 as `-Zno-jump-tables`. * ```@tgross35``` created and maintained the tracking issue #116592, and provided feedback about the naming of the cli option. ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? There are none. ## What static checks are done that are needed to prevent undefined behavior? This option cannot cause undefined behavior. It is a boolean option with well defined behavior in both cases. ## In what way does this feature interact with the reference/specification, and are those edits prepared? This adds a new cli option to `rustc`. The documentation is updated, and the unstable documentation cleaned up in this PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? None. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support is required from other rust tooling. ## Open Items - [x] Are there objections renaming `-Zno-jump-tables` to `-Cjump-tables=<bool>`? The consensus is no. - [x] Is it desirable to keep `-Zno-jump-tables` for a period of time? The consensus is no. --- Closes #116592

Rust 1.93.0 (expected 2026-01-22) is stabilizing `-Zno-jump-tables` [1][2] as `-Cjump-tables=n` [3]. Without this change, one would eventually see: RUSTC L rust/core.o error: unknown unstable option: `no-jump-tables` Thus support the upcoming version. Link: rust-lang/rust#116592 [1] Link: rust-lang/rust#105812 [2] Link: rust-lang/rust#145974 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20251101094011.1024534-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

rustbot assigned TaKO8Ki Dec 17, 2022

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 17, 2022

This was referenced Dec 17, 2022

rustc wanted features & bugfixes Rust-for-Linux/linux#355

Open

objtool warnings in KernelCI report Rust-for-Linux/linux#945

Closed

This comment has been minimized.

Sign in to view

ojeda force-pushed the no-jump-tables branch from 0163d5b to 3612578 Compare December 19, 2022 11:48

rustbot assigned wesleywiser and unassigned TaKO8Ki Dec 20, 2022

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 20, 2022

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 20, 2022

This comment has been minimized.

Sign in to view

nikic reviewed Dec 20, 2022

View reviewed changes

src/test/codegen/no-jump-tables.rs Outdated Show resolved Hide resolved

ojeda force-pushed the no-jump-tables branch from 3612578 to 70c4ea0 Compare December 20, 2022 17:39

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 20, 2022

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 21, 2022

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 21, 2022

bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 21, 2022

bors merged commit a8207df into rust-lang:master Dec 21, 2022

rustbot added this to the 1.68.0 milestone Dec 21, 2022

ojeda deleted the no-jump-tables branch December 21, 2022 20:30

workingjubilee added the A-CLI Area: Command-line interface (CLI) to the compiler label Mar 5, 2023

tgross35 mentioned this pull request Oct 10, 2023

Tracking Issue for no-jump-tables #116592

Closed

6 tasks

ojeda mentioned this pull request Feb 17, 2024

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

pmur mentioned this pull request Aug 28, 2025

Stabilize -Zno-jump-tables into -Cjump-tables=bool #145974

Merged

2 tasks

Add -Zno-jump-tables #105812

Add -Zno-jump-tables #105812

Uh oh!

Conversation

ojeda commented Dec 17, 2022

Uh oh!

rustbot commented Dec 17, 2022

Uh oh!

This comment has been minimized.

TaKO8Ki commented Dec 20, 2022

Uh oh!

nikic commented Dec 20, 2022

Uh oh!

bors commented Dec 20, 2022

Uh oh!

nikic commented Dec 20, 2022

Uh oh!

bors commented Dec 20, 2022

Uh oh!

bors commented Dec 20, 2022

Uh oh!

This comment has been minimized.

Uh oh!

nikic commented Dec 20, 2022

Uh oh!

bors commented Dec 20, 2022

Uh oh!

bors commented Dec 20, 2022

Uh oh!

bors commented Dec 21, 2022

Uh oh!

bors commented Dec 21, 2022

Uh oh!

rust-log-analyzer commented Dec 21, 2022

Uh oh!

nikic commented Dec 21, 2022

Uh oh!

ojeda commented Dec 21, 2022

Uh oh!

bors commented Dec 21, 2022

Uh oh!

bors commented Dec 21, 2022

Uh oh!

rust-timer commented Dec 21, 2022

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Add `-Zno-jump-tables` #105812

Add `-Zno-jump-tables` #105812