Skip to content

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

workingjubilee and others added 13 commits October 27, 2024 20:27
…jgillot

Lower AST node id only once

Fixes rust-lang#96346.

I basically followed the given instructions except the inline part.

`lower_jump_destination` can't reuse local existing `HirId` due to unknown name resolution result so I created an additional mapping for labels.

r? `@cjgillot`
…ir, r=celinval

stable_mir: Directly use types from rustc_abi

In most cases, rustc_target is not necessary, so use rustc_abi instead of its reexports.
…s-margins, r=notriddle

[rustdoc] Unify variant struct fields margins with struct fields

As discussed in rust-lang#132220.

| before | after |
|-|-|
| ![image](https://github.com/user-attachments/assets/d8d8336d-7fe4-45fb-a5a5-36a4023223f5) | ![Screenshot from 2024-10-28 11-17-24](https://github.com/user-attachments/assets/9d0d9633-b857-45b4-9217-7d0d1aa8f770) |

r? `@notriddle`
…r-errors

cg_llvm: Use a type-safe helper to cast `&str` and `&[u8]` to `*const c_char`

In `rustc_codegen_llvm` there are many uses of `.as_ptr().cast()` to convert a string or byte-slice to `*const c_char`, which then gets passed through FFI.

This works, but is fragile, because there's nothing constraining the pointer cast to actually be from `u8` to `c_char`. If the original value changes to something else that has an `as_ptr` method, or the context changes to expect something other than `c_char`, the cast will silently do the wrong thing.

By making the cast more explicit via a helper method, we can be sure that it will either perform the intended cast, or fail at compile time.
…none, r=compiler-errors

refactor: cleaner check to return None

It's very nit change. Refactor to shorten verbose check when returning None for `backend_feature_name`.
@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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 28, 2024
@GuillaumeGomez
Copy link
Member Author

@bors r + p=5

@workingjubilee
Copy link
Member

This has apparently acquired a merge conflict, despite my efforts to not have any of my PRs do that. Ah well. I opened a new rollup.

@bors r-

@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-review Status: Awaiting review from the assignee but also interested parties. labels Oct 28, 2024
@bors
Copy link
Collaborator

bors commented Oct 28, 2024

☔ The latest upstream changes (presumably #132262) made this pull request unmergeable. Please resolve the merge conflicts.

@GuillaumeGomez GuillaumeGomez deleted the rollup-dnzhc18 branch October 28, 2024 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc 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