Add known_issues.md for tracking core language issues

[aclysma]

In today's meeting, we discussed maintaining a list of issues we'd like to raise to the core language team as a markdown file. (#38)

I looked through the bugs in this repo and the embark repo and these are the ones that stood out to me.

Rendered

For discussion:

• Anything to add/remove?
• Is this the right level of detail for each issue?
• Obligatory bikeshedding of filename, location, prose... :)

[AlexEne]

How about making better tags for these? Language/Tooling/etc.
Having a list is kind of duplicating the information.

[Lokathor]

@AlexEne I don't understand what you mean by tags, each bullet list is already broken up by subject.

@aclysma I don't think that showing the full github URL every time is very useful. We could probably just make the item's text a link:

* https://github.com/rust-gamedev/wg/issues/20 - Map/Set in .natvis files

becomes

* [Map/Set in .natvis files](https://github.com/rust-gamedev/wg/issues/20)

[aclysma]

@AlexEne: I almost suggested using a tag. However, we wouldn't be able to apply a tag to issues in other repos. (such as the ones from the embark rust ecosystem repo) We could duplicate external issues and tag the duplicates, if that's what people want to do. Additionally, a markdown doc lets us group/summarize things easily.

@Lokathor: Sounds good

[repi]

Thanks for including / linking in the issues we've run into at Embark!

[AlexEne]

Once one gets fixed, someone needs to remember to clean/update this file that's my only concern. It gets even stranger for external issues. I would duplicate them where it makes sense and then tag. This is what i did with the rls one

[Lokathor]

that's not super different with separate issues though, someone still has to go through and close our copy of the issue.

[AlexEne]

Maybe I didn't express myself in a proper way, sorry, I was in a hurry.
When I created the task for RLS I couldn't link / mention to the one in Embark repo as it was private at the time, but it was in response to seeing that and would make total sense now to do so.

My view is that we should act more in the spirit of creating issues here we can drive a resolution to (of course with mentioning other places like Embark, and others where these originate). In a similar way is the issue that talks about raw_window_handle.

For example there are like a bunch of issues mentioning RLS in this file, just make a mega issue for RLS, link all of them and they are in the "issue" system of github. You get updates when things are closed you linked against, etc.

In other cases maybe it makes sense to make a new "github issue" to actually address some of the problems, not just for sync / book-keeping purposes (RLS breaker issue).

I hope I made it a bit more clear now.
This plus tags looks like a way better system to me.

[est31]

Personally I'd love to see profile-overrides to be stabilized: rust-lang/rust#48683

It takes a ton of time to compile and link my game in release mode. So I often only develop in debug mode but it's too slow unless I enable optimizations for key parts. This isn't possible without that feature (unless local rustc override wrapper is used which has its own set of issues). The feature is the only nightly feature I'm using and I'd prefer to develop on stable one day.

[est31]

Hmm it's already mentioned. nvm then.

[aclysma]

1. Markdown vs. tags: I have no preference, but a decision will need to be made.
2. I didn't see any feedback regarding the content (i.e. which issues are on the list and the grouping/summarization)
3. I'm not sure what the next steps would be after having a list. I guess we could a) find or create rust-lang issues b) ask for them to be triaged and perhaps for mentoring instructions to be added? It's possible some of them (like /fp:fast) are actually low-hanging fruit, or as a temporary workaround could be accomplished by setting an environment variable.

[AlexEne]

Issue list is fine, my vote is having them as issues (linked, tagged, etc.) as it's more of a living thing rather than a md somewhere.

[Lokathor]

just be aware ahead of time that many of the issues will sit doing nothing for months or years, and we can't just close them from lack of recent progress ;P

[kvark]

I don't think issues work best here. Main problem: they are not actionable, they are just tracking. Earlier, we faced a similar need in gfx-rs and end up with a wiki page for all Apple bugs we submitted. It has worked well for us. Therefore, my preference would be to accept the PR as is.

[Lokathor]

I'm gonna merge this and we can edit it later as additional info arrives.