General conflict¶

For general conflicts, the output will look similar to this:

compiler/rustc_abi/Cargo.toml: conflict between lines 18 and 20

Fix the conflict manually and stage the changed files:

git add <FILE_1> <FILE_2> # stages file(s)

If code needs to be added or modified for Ferrocene needs, leave a comment to track the change easily.

Deletion conflict¶

For deletion conflicts, the output will look similar to this:

compiler/rustc_abi/src/layout.rs: file deleted by one side of the merge

This conflict happens when we made changes to a file and it gets deleted by upstream.

Usually this is solved by removing the file:

git rm <FILE_1> <FILE_2> # removes file(s) and stages that change

Apart from deleting the file, it is necessary to make sure that the purpose we changed the file for is preserved. For example if we changed a bootstrap file, we need to port this change to another file. Usually this change needs to happen in the same PR.

In the majority of cases, the deleted file is a test which is renamed or moved. In that case, the annotations must be transferred to the moved or renamed test. If the test with annotations was just deleted, it is necessary to go to the traceability-matrix and see whether the behavior is still covered by another test. That is, the tag is still listed in another test.

As an example, upstream deleted the file tests/ui/consts/miri_unleashed/mutable_references_err.rs:

 <<<PULL-UPSTREAM>>> file deleted upstream; move the Ferrocene annotations if any, and delete this file
// ...
// ferrocene-annotations: fls_qztk0bkju9u
// Borrow Expression
// ...

Please make sure that the fls annotation still exists:

If an annotation is lost, another test that covers that behavior should be found. This can be done in a subsequent PR.

Unknown conflicts and new errors¶

When an error previously unknown appears, such as a library not being found, try to isolate the faulty process that triggered it with ferrocene/ci/split-tasks.py. The list of possible jobs can be found in .circleci/workflow.yml.

Then check upstream for related fixes. If the failure was solved later, close the current PR and pull a new one, including the fix.

Blessing¶

Sometimes, the output of stderr has changed upstream.

Run x test tests/<path-to-failing-tests-folder> --bless