-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
issues can be opened #160
Comments
Read the extremely long thread here first: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html :) |
You basically just made my point. |
@jdoerfert He haven't officially enabled issues, so I'll se if I can find away to close new ones without closing the existing once. |
There will be a non-empty set of issues which would be raised on github, but where the developer sees the overhead of emailing someone at bugzilla to open an account and decides they've got better things to do. I think we should keep github issues available on that basis. |
@JonChesterfield This is why we have discussed switching to GitHub issues long-term, but I do think it's confusing to have them enabled before we've officially switched. |
We should keep this open. Many of the users reporting issues here I believe are not long-term members of our community, and would not open a bugzilla account. We should be welcoming them. |
That was one of the main arguments of the discussion that was going on. I do not disagree. However, welcoming should mean we don't only have a bug tracker open here but also people that monitor it. The people that usually monitor bugs and address them might also find it less welcoming if we have a discussion about moving to issues and just do it while no consensus was reached. To repeat my initial problem: We need to announce this properly either way and we need to set up the infrastructure to make this work seamlessly for people, e.g., emails to the -bugs list. @tstellar Can you send a new email on *-dev to announce "the plan"? |
To repeat myself because I don't think anything changed in the last 12 days: welcoming should mean we don't only have a bug tracker open here but also people that monitor it. To me, it feels like GH issues are still ignored by a huge fraction of the community. It is great that we make it easy for people to report issues and ask questions but I doubt it helps them if they are largely ignored: #73, #95, #97, #115, #122, #147 ... (all) In addition we now have four separate systems that all do similar things with no clear guidance on how to use them... |
That's my feeling as well. We should close the issue until there is a real plan. |
Well, the migration has now happened. Seems safe to close this. |
…114.25 (llvm#160) [objwriter/12.x] Update dependencies from dotnet/arcade
This PR fixes lowering for `break/continue` in loops. The idea is to replace `cir.yield break` and `cir.yield continue` with the branch operations to the corresponding blocks. Note, that we need to ignore nesting loops and don't touch `break` in switch operations. Also, `yield` from `if` need to be considered only when it's not the loop `yield` and `continue` in switch is ignored since it's processed in the loops lowering. Fixes llvm#160
This PR fixes lowering for `break/continue` in loops. The idea is to replace `cir.yield break` and `cir.yield continue` with the branch operations to the corresponding blocks. Note, that we need to ignore nesting loops and don't touch `break` in switch operations. Also, `yield` from `if` need to be considered only when it's not the loop `yield` and `continue` in switch is ignored since it's processed in the loops lowering. Fixes llvm#160
This PR fixes lowering for `break/continue` in loops. The idea is to replace `cir.yield break` and `cir.yield continue` with the branch operations to the corresponding blocks. Note, that we need to ignore nesting loops and don't touch `break` in switch operations. Also, `yield` from `if` need to be considered only when it's not the loop `yield` and `continue` in switch is ignored since it's processed in the loops lowering. Fixes llvm#160
…d related map syntax (llvm#160) * Apply upstream allocatable member mapping with some minor modifications * fix rebase issues * Fix tests
This PR fixes lowering for `break/continue` in loops. The idea is to replace `cir.yield break` and `cir.yield continue` with the branch operations to the corresponding blocks. Note, that we need to ignore nesting loops and don't touch `break` in switch operations. Also, `yield` from `if` need to be considered only when it's not the loop `yield` and `continue` in switch is ignored since it's processed in the loops lowering. Fixes llvm#160
I was surprised but it seems we allow github issues now 0
One unfortunate consequence is that people do not get emails for the new issues as they get them for new bugs (there is some opt-in required or we need to forward emails to the appropriate lists). Is this on purpose? If so, could we announce that more prominently on the lists? If it is not on purpose we should disable Issues for now.
The text was updated successfully, but these errors were encountered: