Skip to content
New issue

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

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

Already on GitHub? Sign in 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
Contributor

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
Contributor

bors commented Jul 19, 2023

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

@bors
Copy link
Contributor

bors commented Jul 19, 2023

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

@bors
Copy link
Contributor

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
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. 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