First things first: the issue tracker is NOT for tech support. It is for reporting bugs and requesting features. If your issue amounts to "I can't get ycmd to work on my machine" and the reason why is obviously related to your machine configuration and the problem would not be resolved with reasonable changes to the ycmd codebase, then the issue is likely to be closed.
A good place to ask questions is the ycmd-users Google group. Rule of thumb: if you're not sure whether your problem is a real bug, ask on the group.
ycmd compiles just fine; the build bots say so. If the bots are green and ycmd doesn't compile on your machine, then your machine is the root cause. Now read the first paragraph again.
Realize that quite literally thousands of people have gotten ycmd to work successfully so if you can't, it's probably because you have a peculiar system or configuration or you didn't go through the docs carefully enough. It's very unlikely to be caused by an actual bug in ycmd because someone would have already found it and reported it.
This leads us to point #2: make sure you have checked the docs before reporting an issue. The docs are extensive and cover a ton of things; there's also an FAQ at the bottom that quite possibly addresses your problem. NOTE: installation of ycmd is predominantly documented in the YouCompleteMe (Vim client) README.
For installation problems, make sure that any issue report includes the entire output of any build or installation commands, including the command used to run them.
Further, search the issue tracker for similar issues before creating a new one. There's no point in duplication; if an existing issue addresses your problem, please comment there instead of creating a duplicate. However, if the issue you found is closed as resolved (e.g. with a PR or the original user's problem was resolved), raise a new issue, because you've found a new problem. Reference the original issue if you think that's useful information.
If you do find a similar open issue, don't just post 'me too' or similar responses. This almost never helps resolve the issue, and just causes noise for the maintainers. Only post if it will aid the maintainers in solving the issue; if there are existing diagnostics requested in the thread, perform them and post the results.
When replying, follow the instructions for getting the required diagnostics for posting a new issue (see below), and add them to your response. This is likely to help the maintainers find a fix for you, rather than have them spend time requesting them again. To be clear, the maintainers always need the diagnostics (debug info, log files, versions, etc.) even for responses on existing issues.
You should also search the archives of the ycmd-users mailing list.
Lastly, make sure you are running the latest version of ycmd. The issue you
have encountered may have already been fixed. Don't forget to recompile
ycm_core.so too (usually by just running build.py
again).
OK, so we've reached this far. You need to create an issue. First realize that the time it takes to fix your issue is a multiple of how long it takes the developer to reproduce it. The easier it is to reproduce, the quicker it'll be fixed.
Here are the things you should do when creating an issue:
/debug_info
request for the file that is
experiencing the issue.server_log_level
option is set to debug
, then reproduce
your issue and attach the contents of the logfiles reported in the debug
info.Follow the code style of the existing codebase.
style_format.sh
that runs
astyle
) but it's not perfect. Again, look at the other C++ files and
match the code style you see.Your code needs to be well written and easy to maintain. This is of the utmost importance. Other people will have to maintain your code so don't just throw stuff against the wall until things kinda work.
Split your pull request into several smaller ones if possible. This makes it easier to review your changes, which means they will be merged faster.
Write tests for your code. Your pull request is unlikely to be merged without tests. See TESTS.md for instructions on running the tests.
Explain in detail why your pull request makes sense. Ask yourself, would this feature be helpful to others? Not just a few people, but a lot of ycmd's users? See, good features are useful to many. If your feature is only useful to you and maybe a couple of others, then that's not a good feature. There is such a thing as “feature overload”. When software accumulates so many features of which most are only useful to a handful, then that software has become “bloated”. We don't want that.
Requests for features that are obscure or are helpful to but a few, or are not part of ycmd's "vision" will be rejected. Yes, even if you provide a patch that completely implements it.
Please include details on exactly what you would like to see, and why. The why is important - it's not always clear why a feature is really useful. And sometimes what you want can be done in a different way if the reason for the change is known. What goal is your change trying to accomplish?
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。