Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Rollup of 7 pull requests #113865

Merged
merged 20 commits into from
Jul 19, 2023
Merged

Rollup of 7 pull requests #113865

merged 20 commits into from
Jul 19, 2023

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

lcnr and others added 20 commits July 13, 2023 13:43
…plied at the crate level.

When `no_builtins` is applied at the crate level, we should add the
`no-builtins` attribute to each function to ensure it takes effect in LTO.
…errors

add tests for alias bound preference

cc rust-lang/trait-system-refactor-initiative#45

r? ``@compiler-errors``
…, r=pnkfelix

Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.

**When `no_builtins` is applied at the crate level, we should add the `no-builtins` attribute to each function to ensure it takes effect in LTO.**

This is also the reason why no_builtins does not take effect in LTO as mentioned in rust-lang#35540.

Now, `#![no_builtins]` should be similar to `-fno-builtin` in clang/gcc, see https://clang.godbolt.org/z/z4j6Wsod5.

Next, we should make `#![no_builtins]` participate in LTO again. That makes sense, as LTO also takes into consideration function-level instruction optimizations, such as the MachineOutliner. More importantly, when a user writes a large `#![no_builtins]` crate, they would like this crate to participate in LTO as well.

We should also add a function-level no_builtins attribute to allow users to have more control over it. This is similar to Clang's `__attribute__((no_builtin))` feature, see https://clang.godbolt.org/z/Wod6KK6eq. Before implementing this feature, maybe we should discuss whether to support more fine-grained control, such as `__attribute__((no_builtin("memcpy")))`.

Related discussions:
- rust-lang#109821
- rust-lang#35540

Next (a separate pull request?):
- [ ] Revert rust-lang#35637
- [ ] Add a function-level `no_builtin` attribute?
…chenkov

Simplify native_libs query

Drive-by cleanup I saw while implementing rust-lang#113734
Make it clearer that edition functions are `>=`, not `==`

r? `@Nilstrieb`

We could also perhaps derive `Ord` on `Edition` and use comparison operators.
… r=eholk

Improve error message when closing bracket interpreted as formatting fill character

Fixes rust-lang#112732 by explaining why it's erroring in the way it is.
…-105735-fix, r=notriddle,aDotInTheVoid

Fix invalid display of inlined re-export when both local and foreign items are inlined

Fixes rust-lang#105735.

The bug is actually quite interesting: at the `clean` pass, local inlined items have their `use` item removed, however foreign items don't have their `use` item removed because it's in the `clean` pass that we handle them. So when a `use` inlines both a local and a foreign item, it will work as expected for the foreign one, but not for the local as its `use` should not be around anymore.

To prevent this, I created a new `inlined_foreigns` field into the `Module` struct to allow to remove the `use` item early on for foreign items as well. Then we iterate it in the `clean` pass directly.

r? ``@notriddle``
…, r=fee1-dead

Fix inline_const with interpolated block

Interpolation already worked when we had a `const $block` that wasn't a statement expr:

```
fn foo() {
  let _ = const $block;
}
```

But it was failing when the const block was in statement expr position:

```
fn foo() {
  const $block;
}
```

... because of a bug in a check for const items. This fixes that.

---

cc rust-lang#112953 (comment), though I don't think this requires an FCP since it's already supported in exprs and seems to me to be fully a parser bug.
@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 Jul 19, 2023
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jul 19, 2023

📌 Commit 6c3cbcd has been approved by Dylan-DPC

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

bors commented Jul 19, 2023

⌛ Testing commit 6c3cbcd with merge 39f42ad...

@bors
Copy link
Collaborator

bors commented Jul 19, 2023

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 39f42ad to master...

@bors
Copy link
Collaborator

bors commented Jul 19, 2023

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 39f42ad to master...

@bors bors added merged-by-bors This PR was explicitly merged by bors. labels Jul 19, 2023
@bors bors merged commit 39f42ad into rust-lang:master Jul 19, 2023
@rustbot rustbot added this to the 1.73.0 milestone Jul 19, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (39f42ad): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.6% [1.6%, 1.6%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results

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.8% [2.8%, 2.8%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.8% [2.8%, 2.8%] 1

Cycles

Results

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.8% [1.1%, 6.1%] 16
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-3.2% [-6.1%, -0.9%] 13
Improvements ✅
(secondary)
-2.3% [-2.3%, -2.3%] 1
All ❌✅ (primary) 0.1% [-6.1%, 6.1%] 29

Binary size

Results

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)
0.5% [0.5%, 0.5%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Bootstrap: 647.681s -> 648.656s (0.15%)

@Dylan-DPC Dylan-DPC deleted the rollup-pt960bk branch July 20, 2023 05:45
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup 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. 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.

9 participants