Skip to content

Conversation

Zalathar
Copy link
Contributor

This PR removes the LLVMRust wrapper functions for getting/setting linkage and visibility, and replaces them with direct calls to the corresponding functions in LLVM's C API.

To make this convenient and sound, two pieces of supporting code have also been added:

  • A simple proc-macro that derives TryFrom<u32> for fieldless enums
  • A wrapper type for C enum values returned by LLVM functions, to ensure soundness if LLVM returns an enum value we don't know about

In a few places, the use of safe wrapper functions means that an unsafe block is no longer needed, so the affected code has changed its indentation level.

@rustbot
Copy link
Collaborator

rustbot commented Oct 26, 2024

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot 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 Oct 26, 2024
@Zalathar
Copy link
Contributor Author

For historical context, these wrappers were added by #36200 and #38117.

There appears to have been a fear of the enums going out of sync with LLVM, but the actual desyncs appear to have been self-inflicted, due to people modifying the Rust-side enum in ways that reflect the unstable C++ enum rather than the stable C enum.

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this looks like a very nice cleanup. I have some minor suggestions, otherwise this LGTM.

@jieyouxu jieyouxu assigned jieyouxu and unassigned TaKO8Ki Oct 26, 2024
@jieyouxu jieyouxu added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 26, 2024
Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. You can r=me after PR CI is green.

@Zalathar
Copy link
Contributor Author

🟩
@bors r=jieyouxu

@bors
Copy link
Collaborator

bors commented Oct 26, 2024

📌 Commit 3e51f6f has been approved by jieyouxu

It is now in the queue for this repository.

@bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 26, 2024
Zalathar added a commit to Zalathar/rust that referenced this pull request Oct 26, 2024
Replace some LLVMRust wrappers with calls to the LLVM C API

This PR removes the LLVMRust wrapper functions for getting/setting linkage and visibility, and replaces them with direct calls to the corresponding functions in LLVM's C API.

To make this convenient and sound, two pieces of supporting code have also been added:
- A simple proc-macro that derives `TryFrom<u32>` for fieldless enums
- A wrapper type for C enum values returned by LLVM functions, to ensure soundness if LLVM returns an enum value we don't know about

In a few places, the use of safe wrapper functions means that an `unsafe` block is no longer needed, so the affected code has changed its indentation level.
@Zalathar
Copy link
Contributor Author

Rebased after trivial conflict with #132168.

@bors r=jieyouxu

@bors
Copy link
Collaborator

bors commented Oct 26, 2024

📌 Commit 2f06853 has been approved by jieyouxu

It is now in the queue for this repository.

jieyouxu added a commit to jieyouxu/rust that referenced this pull request Oct 26, 2024
Replace some LLVMRust wrappers with calls to the LLVM C API

This PR removes the LLVMRust wrapper functions for getting/setting linkage and visibility, and replaces them with direct calls to the corresponding functions in LLVM's C API.

To make this convenient and sound, two pieces of supporting code have also been added:
- A simple proc-macro that derives `TryFrom<u32>` for fieldless enums
- A wrapper type for C enum values returned by LLVM functions, to ensure soundness if LLVM returns an enum value we don't know about

In a few places, the use of safe wrapper functions means that an `unsafe` block is no longer needed, so the affected code has changed its indentation level.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 26, 2024
Rollup of 4 pull requests

Successful merges:

 - rust-lang#132124 (coverage: Consolidate creation of covmap/covfun records)
 - rust-lang#132167 (Replace some LLVMRust wrappers with calls to the LLVM C API)
 - rust-lang#132169 (Deny calls to non-`#[const_trait]` methods in MIR constck)
 - rust-lang#132174 (x86 target features: make pclmulqdq imply sse2)

r? `@ghost`
`@rustbot` modify labels: rollup
@jieyouxu
Copy link
Member

jieyouxu commented Oct 26, 2024

error: `gen` is a keyword in the 2024 edition
  --> compiler/rustc_macros/src/try_from.rs:43:9
   |
43 |         gen impl TryFrom<u32> for @Self {
   |         ^^^ help: you can use a raw identifier to stay compatible: `r#gen`
   = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
   = note: for more information, see issue #49716 <https://github.com/rust-lang/rust/issues/49716>
   = note: for more information, see issue #49716 <https://github.com/rust-lang/rust/issues/49716>
   = note: `-D keyword-idents-2024` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(keyword_idents_2024)]`

@bors r- (failed in #132177)

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 26, 2024
@Zalathar
Copy link
Contributor Author

Zalathar commented Oct 26, 2024

Fixing this is easy enough, but I'm a bit baffled as to why it doesn't fail/warn locally or in PR CI.

@Zalathar
Copy link
Contributor Author

Addressed keyword_idents_2024 warning about gen in the macro (diff).

Since this wasn't found by PR CI, I'll run a side job at #114917 and then reapprove this when that passes.

@rust-log-analyzer

This comment has been minimized.

@Zalathar
Copy link
Contributor Author

Looks like I am not the first person to have this problem with gen and synstructure: #127729.

Given that there's precedent in rustc_macros, I'll just add another #[allow(keyword_idents_2024)] here. Whatever work is needed to fix the existing cases will also fix this one.

@Zalathar
Copy link
Contributor Author

Workaround for the synstructure/gen issue, which already has precedent elsewhere in rustc_macros: (diff).

@jieyouxu
Copy link
Member

jieyouxu commented Oct 27, 2024

This is fine, I'll revisit how bootstrap sets that lint level... it seems somewhat suspicious.

@bors r+ rollup=iffy

@bors
Copy link
Collaborator

bors commented Oct 27, 2024

📌 Commit d976ca8 has been approved by jieyouxu

It is now in the queue for this repository.

@bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 27, 2024
@bors
Copy link
Collaborator

bors commented Oct 27, 2024

⌛ Testing commit d976ca8 with merge be33e4f...

@bors
Copy link
Collaborator

bors commented Oct 27, 2024

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing be33e4f to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 27, 2024
@bors bors merged commit be33e4f into rust-lang:master Oct 27, 2024
7 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Oct 27, 2024
@Zalathar Zalathar deleted the llvm-wrappers branch October 27, 2024 06:38
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (be33e4f): 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)

Results (primary 2.7%, secondary -2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.7% [2.7%, 2.7%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.0% [-2.0%, -1.9%] 2
All ❌✅ (primary) 2.7% [2.7%, 2.7%] 1

Cycles

Results (secondary 1.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.8% [2.6%, 3.1%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.4% [-2.4%, -2.4%] 1
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 782.934s -> 782.771s (-0.02%)
Artifact size: 333.73 MiB -> 333.71 MiB (-0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants