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

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

Merged
merged 1 commit into from
Jul 19, 2023

Conversation

DianQK
Copy link
Member

@DianQK DianQK commented Jul 15, 2023

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 #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:

Next (a separate pull request?):

@rustbot
Copy link
Collaborator

rustbot commented Jul 15, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @b-naber (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@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 Jul 15, 2023
@DianQK
Copy link
Member Author

DianQK commented Jul 15, 2023

r? pnkfelix

@rustbot rustbot assigned pnkfelix and unassigned b-naber Jul 15, 2023
@rust-log-analyzer

This comment has been minimized.

@bjorn3
Copy link
Member

bjorn3 commented Jul 15, 2023

#113684 accidentally got merged due to a glitch in bors. We had to force push it away. It seems that you based this PR on the state of the repo when that PR was still merged. Could you please rebase and drop these commits?

@DianQK DianQK force-pushed the add-no_builtins-to-function branch from 37eeda3 to d7f56b6 Compare July 16, 2023 02:10
@rust-log-analyzer

This comment has been minimized.

@DianQK DianQK force-pushed the add-no_builtins-to-function branch 2 times, most recently from b93fe48 to 063ddbe Compare July 16, 2023 11:50
@DianQK
Copy link
Member Author

DianQK commented Jul 18, 2023

@bjorn3 Are there any outstanding tasks to be completed for this pull request? I think I can revert #35637.

@pnkfelix
Copy link
Member

pnkfelix commented Jul 18, 2023

If I understand correctly, this PR represents a step towards resolving #72140, but this PR on its own won't resolve that issue.

Rather, the plan is: 1. land this PR (PR #113716), and then 2. revert the code change of PR #35637, and we believe that will yield a working overall state that also has issue #72140 resolved. Does that all sound correct, @DianQK ?

(I was going to say something like "revert the code change of PR #35637 while keeping its test intact, but looking at the test added in that PR, I'm not sure it represents end-to-end behavior we are too concerned about preserving in terms of the details of what linker-invocation is generated. Rather, the more important thing is to check that examples like the ones from https://github.com/DianQK/rust-109821-reproducible/ (see also #110606) start passing under the plan outlined here, I think...)

@DianQK
Copy link
Member Author

DianQK commented Jul 18, 2023

Rather, the plan is: 1. land this PR (PR #113716), and then 2. revert the code change of PR #35637, and we believe that will yield a working overall state that also has issue #72140 resolved. Does that all sound correct, @DianQK ?

Yes, I think so.

@pnkfelix
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jul 18, 2023

📌 Commit 063ddbe has been approved by pnkfelix

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 18, 2023
@pnkfelix
Copy link
Member

@bors rollup

@DianQK
Copy link
Member Author

DianQK commented Jul 18, 2023

(I was going to say something like "revert the code change of PR #35637 while keeping its test intact, but looking at the test added in that PR, I'm not sure it represents end-to-end behavior we are too concerned about preserving in terms of the details of what linker-invocation is generated. Rather, the more important thing is to check that examples like the ones from https://github.com/DianQK/rust-109821-reproducible/ start passing under the plan outlined here, I think...)

I think the #35637 test is just to verify the exclusion of crates with the attribute #![no_builtins] from LTO.
We can delete it directly.

I am uncertain about the necessity of the test case from https://github.com/DianQK/rust-109821-reproducible/. In my opinion, it appears to be unnecessary.

@pnkfelix
Copy link
Member

pnkfelix commented Jul 18, 2023

I am uncertain about the necessity of the test case from https://github.com/DianQK/rust-109821-reproducible/. In my opinion, it appears to be unnecessary.

Well, we should do something to check our capability to combine #![no_builtins] with LTO. After all, after you've put in all this effort to find a path to enable us to support that combination of features, we should put some kind of regression test into our test suite. I just figured your test (or something similar) would be the easiest thing to start from.

@DianQK
Copy link
Member Author

DianQK commented Jul 18, 2023

Well, we should do something to check our capable to combine #![no_builtins] with LTO. After all, after you've put in all this effort to find a path to enable us to support that combination of features, we should put some kind of regression test into our test suite. I just figured your test (or something similar) would be the easiest thing to start from.

It appears that @bors is in the process of merging this PR. I might consider submitting another PR to revert #35637, along with an appropriate test case to be considered.

@pnkfelix
Copy link
Member

pnkfelix commented Jul 18, 2023

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

FYI these kinds of changes may need a T-lang design proposal or T-compiler Major Change Proposal.

The proposals may be easy to adopt, but its still good to put them through the discussion process, rather than go straight to putting them up as PR's, unless you personally prefer to try to express your design ideas via PR's (but even then, a lot of people prefer to read design ideas in a format that is not a low-level PR.)

@pnkfelix
Copy link
Member

Well, we should do something to check our capable to combine #![no_builtins] with LTO. After all, after you've put in all this effort to find a path to enable us to support that combination of features, we should put some kind of regression test into our test suite. I just figured your test (or something similar) would be the easiest thing to start from.

It appears that @bors is in the process of merging this PR. I might consider submitting another PR to revert #35637, along with an appropriate test case to be considered.

Oh, I'm sorry, I wasn't clear.

I wasn't saying that you should incorporate those test cases onto this PR.

that wouldn't make sense anyway, since this PR is only a small step towards the goal.

I was just trying to make sure it was clear that the overall plan would need some kind of test from somewhere, especially since the test from #35637 wasn't exactly checking a big picture end-to-end behavior (it was more of a white-box test).

@bors bors merged commit c1d6d32 into rust-lang:master Jul 19, 2023
@rustbot rustbot added this to the 1.73.0 milestone Jul 19, 2023
tamird added a commit to aya-rs/aya that referenced this pull request Jul 27, 2023
This commit removes memset and memcpy, relying instead on
implementations provided by std/compiler-builtins.

This commit adds `#![no_builtins]` to all the BPF programs written in
Rust, and the same should be propagated to aya-template and all examples
in the book and elsewhere before this commit is merged.

It turns out that without the `#![no_builtins]` annotation rustc
generates LLVM IR that calls LLVM intrinsics rather than libcalls. These
may end up as libcalls after lowering, but not before emitting errors in
BPF lowering[0].

This works thanks to rust-lang/rust#113716 which
causes `#![no_builtins]` to behave similarly to `-fno-builtin` in clang,
which was added in https://reviews.llvm.org/D68028 with similar
motivation.

This commit implies that we now require rustc nightly >= 2023-07-20.

[0] https://github.com/llvm/llvm-project/blob/7b2745b/llvm/lib/Target/BPF/BPFISelLowering.cpp#L472-L474
tamird added a commit to aya-rs/aya that referenced this pull request Jul 27, 2023
This commit removes memset and memcpy, relying instead on
implementations provided by std/compiler-builtins.

This commit adds `#![no_builtins]` to all the BPF programs written in
Rust, and the same should be propagated to aya-template and all examples
in the book and elsewhere before this commit is merged.

It turns out that without the `#![no_builtins]` annotation rustc
generates LLVM IR that calls LLVM intrinsics rather than libcalls. These
may end up as libcalls after lowering, but not before emitting errors in
BPF lowering[0].

This works thanks to rust-lang/rust#113716 which
causes `#![no_builtins]` to behave similarly to `-fno-builtin` in clang,
which was added in https://reviews.llvm.org/D68028 with similar
motivation.

This commit implies that we now require rustc nightly >= 2023-07-20.

[0] https://github.com/llvm/llvm-project/blob/7b2745b/llvm/lib/Target/BPF/BPFISelLowering.cpp#L472-L474
@DianQK DianQK deleted the add-no_builtins-to-function branch August 7, 2023 02:44
DianQK added a commit to DianQK/rust that referenced this pull request Aug 10, 2023
After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.
`#![no_builtins]` with LTO does not result in undefined references to the error.
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 14, 2023
Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/

I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`.

- [x] Fixes rust-lang#72140. ❌ ✅
- [x] Fixes rust-lang#112245. ❌ ✅
- [x] Fixes rust-lang#110606. ❌ ✅
- [ ] Fixes rust-lang#105734.
- [ ] Fixes rust-lang#96486.
- [ ] Fixes rust-lang#108853.
- [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅
- [ ] Fixes rust-lang#108893.
- [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
DianQK added a commit to DianQK/rust that referenced this pull request Sep 26, 2023
After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.
`#![no_builtins]` with LTO does not result in undefined references to the error.
DianQK added a commit to DianQK/rust that referenced this pull request Sep 26, 2023
After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.
`#![no_builtins]` with LTO does not result in undefined references to the error.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 12, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/

I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`.

- [x] Fixes rust-lang#72140. ❌ ✅
- [x] Fixes rust-lang#112245. ❌ ✅
- [x] Fixes rust-lang#110606. ❌ ✅
- [ ] Fixes rust-lang#105734.
- [ ] Fixes rust-lang#96486.
- [ ] Fixes rust-lang#108853.
- [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅
- [ ] Fixes rust-lang#108893.
- [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
DianQK added a commit to DianQK/rust that referenced this pull request Oct 15, 2023
After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.
`#![no_builtins]` with LTO does not result in undefined references to the error.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 17, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/

I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`.

- [x] Fixes rust-lang#72140. ❌ ✅
- [x] Fixes rust-lang#112245. ❌ ✅
- [x] Fixes rust-lang#110606. ❌ ✅
- [ ] Fixes rust-lang#105734.
- [ ] Fixes rust-lang#96486.
- [ ] Fixes rust-lang#108853.
- [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅
- [ ] Fixes rust-lang#108893.
- [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 26, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 27, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 28, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
tamird added a commit to aya-rs/aya that referenced this pull request Nov 7, 2023
This commit removes memset and memcpy, relying instead on
implementations provided by std/compiler-builtins.

This commit adds `#![no_builtins]` to all the BPF programs written in
Rust, and the same should be propagated to aya-template and all examples
in the book and elsewhere before this commit is merged.

It turns out that without the `#![no_builtins]` annotation rustc
generates LLVM IR that calls LLVM intrinsics rather than libcalls. These
may end up as libcalls after lowering, but not before emitting errors in
BPF lowering[0].

This works thanks to rust-lang/rust#113716 which
causes `#![no_builtins]` to behave similarly to `-fno-builtin` in clang,
which was added in https://reviews.llvm.org/D68028 with similar
motivation.

This commit implies that we now require rustc nightly >= 2023-07-20.

[0] https://github.com/llvm/llvm-project/blob/7b2745b/llvm/lib/Target/BPF/BPFISelLowering.cpp#L472-L474
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 14, 2023
Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 16, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 16, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 30, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 1, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 1, 2023
…kfelix

Restore `#![no_builtins]` crates participation in LTO.

After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again.

`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes rust-lang#72140.  Fixes rust-lang#112245. Fixes rust-lang#110606.  Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

 The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

9 participants