vieter-v
/
v
2
0
Fork 0
Code Issues Pull Requests Releases Activity

doc: fix line breaks to make it 80 characters / line

pull/5112/head
Miller 2020-05-29 07:05:04 +06:00 committed by GitHub
parent 7e538d7401
commit a849d46e3f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
CONTRIBUTING.md
View File

@ -8,15 +8,16 @@ full of magic that only few people understand.
The V compiler is modular, and can be used by other applications. It is located The V compiler is modular, and can be used by other applications. It is located
in `cmd/v/` and `vlib/v/`. in `cmd/v/` and `vlib/v/`.
The most important and useful command to remember when working on the V compiler is The most important and useful command to remember when working on the V compiler
`v self`. is `v self`.
It rebuilds the V compiler. It rebuilds the V compiler.
Be careful, if you introduce a breaking change and rebuild V, you will no longer be able to use V to build Be careful, if you introduce a breaking change and rebuild V, you will no longer
itself. So it's a good idea to make a backup copy of a working compiler executable. be able to use V to build itself. So it's a good idea to make a backup copy of a
working compiler executable.
But don't worry, you can always simply run `make`, it will download the C version of the compiler But don't worry, you can always simply run `make`, it will download the C
and rebuild it from scratch. version of the compiler and rebuild it from scratch.
The main files are: The main files are:
@ -36,8 +37,8 @@ them to tokens.
couple of helper functions. couple of helper functions.
4. `v/parser` The parser. It converts a list of tokens into an AST. 4. `v/parser` The parser. It converts a list of tokens into an AST.
In V, objects can be used before declaration, so unknown types are marked as unresolved. In V, objects can be used before declaration, so unknown types are marked as
They are resolved later in the type checker. unresolved. They are resolved later in the type checker.
5. `v/table` V creates one table object that is shared by all parsers. It 5. `v/table` V creates one table object that is shared by all parsers. It
contains all types, consts, and functions, as well as several helpers to search contains all types, consts, and functions, as well as several helpers to search
@ -73,13 +74,14 @@ accordingly in the steps below.)
1. Fork https://github.com/vlang/v using GitHub's interface to your own account. 1. Fork https://github.com/vlang/v using GitHub's interface to your own account.
Let's say that the forked repository is at Let's say that the forked repository is at
`https://github.com/YOUR_GITHUB_USERNAME/v` . `https://github.com/YOUR_GITHUB_USERNAME/v` .
2. Clone the main v repository https://github.com/vlang/v to a local folder on your computer, say named nv/ 2. Clone the main v repository https://github.com/vlang/v to a local folder on
(`git clone https://github.com/vlang/v nv`) your computer, say named nv/ (`git clone https://github.com/vlang/v nv`)
3. `cd nv` 3. `cd nv`
4. `git remote add pullrequest https://github.com/YOUR_GITHUB_USERNAME/v` 4. `git remote add pullrequest https://github.com/YOUR_GITHUB_USERNAME/v`
NB: the remote named `pullrequest` should point to YOUR own forked repo, not the main v repository! NB: the remote named `pullrequest` should point to YOUR own forked repo, not the
After this, your local cloned repository is prepared for making pullrequests, main v repository! After this, your local cloned repository is prepared for
and you can just do normal git operations such as: `git pull` `git status` and so on. making pullrequests, and you can just do normal git operations such as:
`git pull` `git status` and so on.
5. When finished with a feature/bugfix/change, you can: 5. When finished with a feature/bugfix/change, you can:
`git checkout -b fix_alabala` `git checkout -b fix_alabala`
@ -90,11 +92,14 @@ Here the UI shows a dialog with a button to make a new pull request based on
the new pushed branch. the new pushed branch.
(Example dialog: https://url4e.com/gyazo/images/364edc04.png) (Example dialog: https://url4e.com/gyazo/images/364edc04.png)
8. After making your pullrequest (aka, PR), you can continue to work on the 8. After making your pullrequest (aka, PR), you can continue to work on the
branch `fix_alabala` ... just do again `git push pullrequest` when you have more commits. branch `fix_alabala` ... just do again `git push pullrequest` when you have more
commits.
9. If there are merge conflicts, or a branch lags too much behind V's master, 9. If there are merge conflicts, or a branch lags too much behind V's master,
you can do the following: you can do the following:
1. `git pull --rebase origin master` # solve conflicts and do `git rebase --continue` 1. `git pull --rebase origin master` # solve conflicts and do
2. `git push pullrequest -f` # this will overwrite your current remote branch with the updated version of your changes. `git rebase --continue`
2. `git push pullrequest -f` # this will overwrite your current remote branch
with the updated version of your changes.
The point of doing the above steps, is to never directly push to the main V The point of doing the above steps, is to never directly push to the main V
repository, *only to your own fork*. Since your local `master` branch tracks the repository, *only to your own fork*. Since your local `master` branch tracks the
@ -120,7 +125,8 @@ NB: You still need to have a GitHub account.
2. `cd my_v` 2. `cd my_v`
3. `hub fork --remote-name pullrequest` 3. `hub fork --remote-name pullrequest`
4. `git checkout -b my_cool_feature` # Step 4 is better done *once per each new feature/bugfix* that you make. 4. `git checkout -b my_cool_feature` # Step 4 is better done *once per each new
feature/bugfix* that you make.
### Improve V by making commits: ### Improve V by making commits: