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

issues can be opened #160

Closed
jdoerfert opened this issue Feb 29, 2020 · 11 comments
Closed

issues can be opened #160

jdoerfert opened this issue Feb 29, 2020 · 11 comments

Comments

@jdoerfert
Copy link
Member

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.

@DimitryAndric
Copy link
Collaborator

Read the extremely long thread here first: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html :)

@jdoerfert
Copy link
Member Author

Read the extremely long thread here first: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html :)

You basically just made my point.

@tstellar
Copy link
Collaborator

tstellar commented Mar 2, 2020

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

@JonChesterfield
Copy link
Collaborator

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.

@tstellar
Copy link
Collaborator

tstellar commented Mar 2, 2020

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

@jyknight
Copy link
Member

jyknight commented Mar 2, 2020

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.

@jdoerfert
Copy link
Member Author

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"?

@andrewrk
Copy link
Member

andrewrk commented Mar 2, 2020

#163 (comment)

@jdoerfert
Copy link
Member Author

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.

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

@joker-eph
Copy link
Collaborator

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

That's my feeling as well.
The issues were opened with the expectation of a migration: but GH issues are not there yet in terms of features as far as I can tell. Having two different bug-trackers is not a good situation to be in.

We should close the issue until there is a real plan.

@sam-mccall
Copy link
Collaborator

Well, the migration has now happened. Seems safe to close this.

am11 pushed a commit to am11/llvm-project that referenced this issue Mar 29, 2022
…114.25 (llvm#160)

[objwriter/12.x] Update dependencies from dotnet/arcade
lanza pushed a commit to lanza/llvm-project that referenced this issue Feb 8, 2024
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
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
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
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
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
mjklemm pushed a commit to mjklemm/llvm-project that referenced this issue Sep 26, 2024
…d related map syntax (llvm#160)

* Apply upstream allocatable member mapping with some minor modifications

* fix rebase issues

* Fix tests
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants