diff --git a/clang/docs/checkedc/3C/CONTRIBUTING.md b/clang/docs/checkedc/3C/CONTRIBUTING.md index 9d807b30d144..2dd30fedaa30 100644 --- a/clang/docs/checkedc/3C/CONTRIBUTING.md +++ b/clang/docs/checkedc/3C/CONTRIBUTING.md @@ -1,7 +1,7 @@ # Contributing to 3C Issues and pull requests related to 3C should be submitted to -[checkedc](https://github.com/checkedc/checkedc-llvm-project) repo. +[checkedc](https://github.com/checkedc/checkedc-clang) repo. ## Issues diff --git a/clang/docs/checkedc/3C/INSTALL.md b/clang/docs/checkedc/3C/INSTALL.md index 0a2385288125..ee5d1a2400cb 100644 --- a/clang/docs/checkedc/3C/INSTALL.md +++ b/clang/docs/checkedc/3C/INSTALL.md @@ -19,15 +19,15 @@ fiddly](#mac-os-x), but we have managed it so far. ## Basics -Start by cloning [checkedc](https://github.com/checkedc/checkedc-llvm-project) repo (or, of course, a +Start by cloning [checkedc](https://github.com/checkedc/checkedc-clang) repo (or, of course, a third-party fork, though we can't be responsible for that). Assuming you have already cloned one of these repositories, run the following -(from the `checkedc-llvm-project` directory or whatever you named your clone) +(from the `checkedc-clang` directory or whatever you named your clone) for a basic build: ``` # Get a copy of the Checked C system headers. Use Microsoft's -# "checkedc" repository regardless of which "checkedc-llvm-project" +# "checkedc" repository regardless of which "checkedc-clang" # repository you use. git clone https://github.com/microsoft/checkedc llvm/projects/checkedc-wrapper/checkedc diff --git a/clang/docs/checkedc/3C/README.md b/clang/docs/checkedc/3C/README.md index 5f37db2e8264..08455e8d4733 100644 --- a/clang/docs/checkedc/3C/README.md +++ b/clang/docs/checkedc/3C/README.md @@ -26,15 +26,15 @@ found [here](https://3clsp.github.io/). ## What 3C users should know about the development process The development of Checked C exclusively takes place in the repository -located at https://github.com/checkedc/checkedc-llvm-project. 3C is included +located at https://github.com/checkedc/checkedc-clang. 3C is included in the Checked C codebase. Initially 3C development was led by [Correct Computation, Inc.](https://correctcomputation.com/). As of now, 3C is -integrated into [checkedc](https://github.com/checkedc/checkedc-llvm-project) -checkedc-llvm-project repo and all furthur development will be in -[checked](https://github.com/checkedc/checkedc-llvm-project) repo. +integrated into [checkedc](https://github.com/checkedc/checkedc-clang) +checkedc-clang repo and all furthur development will be in +[checked](https://github.com/checkedc/checkedc-clang) repo. Issues and pull requests related to 3C should be submitted to -[checkedc](https://github.com/checkedc/checkedc-llvm-project) +[checkedc](https://github.com/checkedc/checkedc-clang) repository; see [CONTRIBUTING.md](CONTRIBUTING.md) for more information. @@ -44,4 +44,4 @@ establish its public presence and processes. As noted in the [setup instructions](INSTALL.md#basics), both 3C and the Checked C compiler depend on the Checked C system headers, which Microsoft maintains in [a subdirectory of a separate repository named -`checkedc`](https://github.com/microsoft/checkedc/tree/master/include). +`checkedc`](https://github.com/microsoft/checkedc/tree/main/include). diff --git a/clang/docs/checkedc/Setup-and-Build.md b/clang/docs/checkedc/Setup-and-Build.md index 563ca7d1d499..3fdb414c6f86 100644 --- a/clang/docs/checkedc/Setup-and-Build.md +++ b/clang/docs/checkedc/Setup-and-Build.md @@ -72,7 +72,7 @@ See the file LICENSE.TXT in for complete details of licensing. The LLVM/Clang repo has two branches: -- master: the main development branch for Checked C. All changes committed here +- main: the main development branch for Checked C. All changes committed here have been code reviewed and passed testing. - baseline: these are pristine copies of the Github mirrors. Do not commit changes for Checked C to the baseline branches. @@ -87,7 +87,7 @@ compiler. The Checked C repo tests are licensed under the [MIT license](https://opensource.org/licenses/MIT). The [Checked C LLVM Test Suite](http://github.com/checkedc/checkedc-llvm-test-suite) is a fork of the -[LLVM test suite mirror](https://github.com/llvm-mirror/test-suite). The LLVM +[LLVM test suite mirror](https://github.com/llvm/llvm-test-suite). The LLVM test suite is for extended testing and includes applications and benchmarks. Some of these benchmarks have been modified to use Checked C extensions. @@ -95,7 +95,7 @@ We do not recommend that developers install sources for it or the Checked C version by default. The test suite is meant to be run as part of automated integration testing or for changes that require extensive testing, not as part of day-to-day development. For developers who need to install it, information is -[here](https://github.com/checkedc/checkedc-llvm-test-suite/blob/master/README.md). +[here](https://github.com/checkedc/checkedc-llvm-test-suite/blob/main/README.md). ## Checkout and Build Instructions for Checked C Compiler @@ -116,7 +116,7 @@ directory as \. 2. Clone the `checkedc-clang` repository: ``` - git clone https://github.com/checkedc/checkedc-llvm-project src + git clone https://github.com/checkedc/checkedc-clang src ``` 3. The Checked C language header files and tests are stored in a folder within @@ -203,7 +203,7 @@ directory as \. In your Visual Studio Command Prompt: Unix/Linux directions. Otherwise, follow these directions: ``` - git clone -c core.autocrlf=false https://github.com/checkedc/checkedc-llvm-project src + git clone -c core.autocrlf=false https://github.com/checkedc/checkedc-clang src ``` 3. The Checked C language header files and tests are stored in a folder within `llvm\project`. @@ -293,5 +293,5 @@ directory to the build directory, and run Most developers can ignore this section. We periodically update the Checked C source code to newer versions of the source code for LLVM/Clang. The directions -for the process of updating the baseline and master branches to newer versions +for the process of updating the baseline and main branches to newer versions of LLVM/Clang are [here](Update-to-latest-LLVM-sources.md). diff --git a/clang/docs/checkedc/Update-to-latest-LLVM-sources.md b/clang/docs/checkedc/Update-to-latest-LLVM-sources.md index 14f1fbcd1f9b..81ba915ea4e3 100644 --- a/clang/docs/checkedc/Update-to-latest-LLVM-sources.md +++ b/clang/docs/checkedc/Update-to-latest-LLVM-sources.md @@ -1,13 +1,13 @@ # Instructions for updating to the latest LLVM/Clang sources We are staying in sync with the upstream LLVM/Clang repository. The `baseline` -branch of the `checkedc-llvm-project` repository is a pristine copy of LLVM/Clang -sources, and the `master` branch contains LLVM/Clang sources plus the support +branch of the `checkedc-clang` repository is a pristine copy of LLVM/Clang +sources, and the `main` branch contains LLVM/Clang sources plus the support for Checked C language extensions. We periodically upgrade the `baseline` branch -and the `master` branch to the sources of the most recent releases from the +and the `main` branch to the sources of the most recent releases from the upstream LLVM/Clang repository. -The branching and merging policies of the `checkedc-llvm-project` repository are +The branching and merging policies of the `checkedc-clang` repository are aligned with the versioning and branching of upstream LLVM/Clang repository in order to closely follow the LLVM/Clang releases. LLVM/Clang releases are versioned as <major-version>.<minor-version>.<patch-version>. @@ -19,13 +19,13 @@ is created. Bug fixes go on the release branch and only some of these bug fixes get merged back into the `main` branch. Typically, LLVM/Clang makes two final releases for each major version. -Now we describe our approach for upgrading the `checkedc-llvm-project` repository to +Now we describe our approach for upgrading the `checkedc-clang` repository to LLVM/Clang sources corresponding to the two releases for each major version, for example, 12.0.0 and 12.0.1. The upgrade is performed in two phases as described below. This description is followed by detailed instructions for each phase. -**Phase 1**: We upgrade the `master` branch of the `checkedc-llvm-project` repository +**Phase 1**: We upgrade the `main` branch of the `checkedc-clang` repository up to the commit hash on the `main` branch of the LLVM/Clang repository at which the branch `release/12.x` is created - we shall refer to this commit hash as <branch-point-of-12-on-main>. We get this commit hash by executing the @@ -34,23 +34,23 @@ repository. Note that <branch-point-of-12-on-main> needs to be the full commit hash and not just the 7-digit abbreviation. This phase constitutes the major portion of the developer effort towards the merge. -**Phase 2**: We create a branch called `release_12.x` off the `master` branch in -the `checkedc-llvm-project` repository. Then there are two sub-phases: +**Phase 2**: We create a branch called `release_12.x` off the `main` branch in +the `checkedc-clang` repository. Then there are two sub-phases: - When we wish to make a Checked C compiler release based on the 12.0.0 release of LLVM/Clang: - - We first upgrade the `release_12.x` branch (of the `checkedc-llvm-project` + - We first upgrade the `release_12.x` branch (of the `checkedc-clang` repository) to the sources corresponding to the 12.0.0 release on the `release/12.x` branch of the LLVM/Clang repository. - - Next, we merge Checked C features and bug fixes from the `master` branch + - Next, we merge Checked C features and bug fixes from the `main` branch to the `release_12.x` branch. - The release of the Checked C compiler happens from the `release_12.x` branch. - When we wish to make a Checked C compiler release based on the 12.0.1 release of LLVM/Clang: - - We upgrade the same `release_12.x` branch (of the `checkedc-llvm-project` + - We upgrade the same `release_12.x` branch (of the `checkedc-clang` repository) to the sources corresponding to the 12.0.1 release on the `release/12.x` branch of the LLVM/Clang repository. - - Next, we merge Checked C features and bug fixes from the `master` branch + - Next, we merge Checked C features and bug fixes from the `main` branch to the `release_12.x` branch. - The release of the Checked C compiler happens from the `release_12.x` branch. @@ -62,11 +62,11 @@ repository will break Checked C build and tests. Note that Phase 1 and the sub-phases of Phase 2 may not be executed one after another in one continuous stretch. They may be spread over several weeks and may -be interspersed with Checked C development on the `master` branch. +be interspersed with Checked C development on the `main` branch. ## Detailed Instructions - Phase 1 -1. Create a new branch off the `baseline` branch in the `checkedc-llvm-project` +1. Create a new branch off the `baseline` branch in the `checkedc-clang` repository. Let us call this new branch `updated_baseline`. ``` git checkout -b updated_baseline baseline @@ -87,20 +87,20 @@ branch `updated_baseline` to be a descendant of branch `baseline`. git checkout baseline git merge --ff-only updated_baseline ``` -5. Create a new branch, say, `updated_baseline_master_12` from the `baseline` +5. Create a new branch, say, `updated_baseline_main_12` from the `baseline` branch. ``` - git checkout -b updated_baseline_master_12 baseline + git checkout -b updated_baseline_main_12 baseline ``` -6. Merge the `master` branch of the checkedc-llvm-project repository into the -`updated_baseline_master_12` branch. This merge may cause several merge +6. Merge the `main` branch of the checkedc-clang repository into the +`updated_baseline_main_12` branch. This merge may cause several merge conflicts and test case failures. After the merge command, git may suggest to you to set `merge.renamelimit` to a specific value. It is a good idea to set it as suggested and re-run the merge. The last section in this document gives guidelines on fixing the merge conflicts and test failures. ``` - git checkout updated_baseline_master_12 - git merge master > merge_conflict_list.txt + git checkout updated_baseline_main_12 + git merge main > merge_conflict_list.txt ``` 7. The resolution of test failures may require you to cherry-pick commits from the upstream LLVM/Clang repository. Record the cherry-picked commits in the @@ -112,45 +112,45 @@ repository. git cherry-pick -x ``` 8. While the merge conflicts and test failures are being fixed, it is possible -that the `master` branch has had several commits. Merge the `master` branch into -`updated_baseline_master_12` branch, and resolve the new conflicts and failures +that the `main` branch has had several commits. Merge the `main` branch into +`updated_baseline_main_12` branch, and resolve the new conflicts and failures if necessary. ``` - git merge master >> merge_conflict_list.txt + git merge main >> merge_conflict_list.txt ``` 9. After all the merge conflicts and test failures on the local machine are -fixed, push the `baseline` and `updated_baseline_master_12` branches to the +fixed, push the `baseline` and `updated_baseline_main_12` branches to the remote repository and execute the ADO tests on branch -`updated_baseline_master_12`. Commits to the `master` branch should be held off +`updated_baseline_main_12`. Commits to the `main` branch should be held off during the final execution of these tests, i.e. just prior to executing step 10 below. ``` git push origin baseline - git push origin updated_baseline_master_12 + git push origin updated_baseline_main_12 ``` -10. After the ADO tests are successful, merge the `updated_baseline_master_12` -branch into `master` and push to the remote repository. If all the changes on -the `master` branch have been merged into the `updated_baseline_master_12` +10. After the ADO tests are successful, merge the `updated_baseline_main_12` +branch into `main` and push to the remote repository. If all the changes on +the `main` branch have been merged into the `updated_baseline_main_12` branch in step 8, then it should be possible to do a fast-forward merge of -branch `updated_baseline_master_12` into the `master` branch. +branch `updated_baseline_main_12` into the `main` branch. ``` - git checkout master - git merge --ff-only updated_baseline_master_12 - git push origin master + git checkout main + git merge --ff-only updated_baseline_main_12 + git push origin main ``` ## Detailed Instructions - Phase 2 We give the instructions for the first sub-phase of Phase 2. Similar steps have to be followed for the other sub-phase. -1. Create a new branch, called `release_12.x`, from the `master` branch in the -`checkedc-llvm-project` repository. If the branch already exists, then merge the -`master` branch into it. Resolve merge conflicts and test failures if any. +1. Create a new branch, called `release_12.x`, from the `main` branch in the +`checkedc-clang` repository. If the branch already exists, then merge the +`main` branch into it. Resolve merge conflicts and test failures if any. ``` - git checkout -b release_12.x master + git checkout -b release_12.x main OR git checkout release_12.x - git merge master + git merge main ``` 2. Upgrade the branch `release_12.x` to the LLVM/Clang sources corresponding to the 12.0.0 release. The commit hash associated with the 12.0.0 release is given @@ -188,20 +188,20 @@ on GitHub. Just push the branches up to GitHub. 1. When `merge.renamelimit` is set to a large value, the output of the `git merge` command may have several lines like: - - CONFLICT (rename/delete): ... in master renamed to ... in HEAD. Version + - CONFLICT (rename/delete): ... in main renamed to ... in HEAD. Version HEAD ... left in tree. - - CONFLICT (rename/delete): ... in master renamed to ... in HEAD. Version - master ... left in tree. + - CONFLICT (rename/delete): ... in main renamed to ... in HEAD. Version + main ... left in tree. If the version in HEAD is left in tree, it is very likely a valid change - - the file may have been moved. If the version in `master` is left in tree, + the file may have been moved. If the version in `main` is left in tree, the files may be valid files that have been added as part of Checked C support: - `llvm/projects/checkedc-wrapper/lit.site.cfg.py` - `llvm/projects/checkedc-wrapper/lit.cfg.py` Others may need more investigation. For example, in the LLVM/Clang 11 to 12 - merge, two files which were reported by git as "Version master ... left in + merge, two files which were reported by git as "Version main ... left in tree" were old versions lying around that needed to be deleted: - `clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTAPI.h` - `clang/include/clang/AST/TypeNodes.def` @@ -209,8 +209,8 @@ on GitHub. Just push the branches up to GitHub. 2. While resolving merge conflicts, it is a good idea to have three reference code snapshots to perform diffs of individual files to help distinguish between checkedc-specific changes and llvm-11-to-12 changes: - - The `master` branch of the `checkedc-llvm-project` repository at the commit hash - which was merged into `updated_baseline_master_12`. + - The `main` branch of the `checkedc-clang` repository at the commit hash + which was merged into `updated_baseline_main_12`. - The pristine LLVM/Clang source at <branch-point-of-11-on-main> - The pristine LLVM/Clang source at <branch-point-of-12-on-main> @@ -218,15 +218,15 @@ checkedc-specific changes and llvm-11-to-12 changes: merge from LLVM 11 to 12 in phase 1 step 6. For a merge of additional Checked C feature development in phase 1 step 8, here are the relevant snapshots and their commit hashes, which we get from the in-progress merge: - - A snapshot of branch `updated_baseline_master_12` after phase 1 step 7, or + - A snapshot of branch `updated_baseline_main_12` after phase 1 step 7, or an earlier iteration of step 8. The commit hash that corresponds to this snapshot is `HEAD` - use command `git rev-parse HEAD` to dump the commit hash. - - A snapshot of the `master` branch that participated in the previous merge + - A snapshot of the `main` branch that participated in the previous merge that produced the above snapshot. The commit hash that corresponds to this snapshot is the common ancestor - use command `git merge-base HEAD MERGE_HEAD` to dump the commit hash. - - A snapshot of the current `master` branch. The commit hash that + - A snapshot of the current `main` branch. The commit hash that corresponds to this is `MERGE_HEAD` - use command `git rev-parse MERGE_HEAD` to dump the commit hash.