-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Guide: comments #15374
Guide: comments #15374
Conversation
return | ||
Now that we have some functions, it's a good idea to learn about comments. | ||
Comments are notes that you leave to other programmers to help explain things | ||
about your code. The compiler ignores them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't ignore doc comments entirely...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(e.g. it can and will complain about
fn foo() {
let a = 0u;
/// descriptive comment
let b = 1u;
}
because doc comments can only be attached to items.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair. Do you think this is too detailed a point to put into an introduction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"the compiler mostly ignores them"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Added in the 'mostly. |
I'm leaving off `rustdoc` usage because it won't work unless this is a `pub fn`, and I want to talk about public/private in the context of modules. I'm also not mentioning `//!` because it is exclusively used to provide the overview of a module.
feat: Implement extern crate completion Hi, this is a draft PR for rust-lang#13002. I have basic completion working as well as a filter for existing extern crate imports in the same file. This is based on the tests, I have not actually tried this in an editor. Before going further I think this is a good point to stop and get feedback on the structure and approach I have taken so far. Let me know what you think :) I will make sure to add more tests, rebase commits and align with the code style guidelines before submitting a final version. A few specific questions : 1. Is there a better way to check for matching suggestions? right now I just test if an extern crate name starts with the current user input. 2. Am I creating the `CompletionItem` correctly? I noticed that `use_.rs` invokes a builder where as I do not. 3. When checking for existing extern crate imports the current implementation only looks at the current source file, is that sufficient?
I'm leaving off
rustdoc
usage because it won't work unless this is apub fn
, and I want to talk about public/private in the context of modules. I'm also not mentioning//!
because it is exclusively used to provide the overview of a module.