chore: Rename Config to GlobalContext

[Muscraft]

This PR :

• renames Config to GlobalContext
  • it also renames its references to gctx (including lifetimes)
  • This was done to reflect better what it really is at this point
• renames (and moves) core::compiler::context::Context to core::compiler::build_runner::BuildRunner
  • Suggested here

I believe I got all references to Config removed, Everything is on GlobalContext, but I could've missed renaming a variable or lifetime somewhere. I tried to find all references to config: &GlobalContext and rename them and I think I did so successfully. I also renamed all 'cfg to 'gctx.

Note: I explicitly did not rename any files or paths as I was unsure about the best way to do this.

How to Review this PR

Take your time (and many breaks)!

I am sorry.

I am also sorry for the very brief description, looking at words and thinking about them has become hard... I need to not look at words for a while...

---

As a complete side note, I honestly don't know if config, Config, ctx, or Context are really words at this point.

[rustbot]

r? @ehuss

(rustbot has picked a reviewer for you, use r? to override)

[weihanglo]

Bikeshedding: GlobalContext or Cargo Context which might be better and good for text search?

[ehuss]

Another bit of bikeshedding, I'm a little concerned that BuildContext and CompileContext might be confusing since in my mind those two words are essentially synonyms of one another. I'm not sure if anyone has other ideas? Maybe Context could be BuildRunner, to emphasize that it handles the actual process of running the build?

[bors]

☔ The latest upstream changes (presumably #13410) made this pull request unmergeable. Please resolve the merge conflicts.

[Muscraft]

Bikeshedding: GlobalContext or Cargo Context which might be better and good for text search?

I am fine with GlobalContext and making the variable gctx if everyone else is.

Another bit of bikeshedding, I'm a little concerned that BuildContext and CompileContext might be confusing since in my mind those two words are essentially synonyms of one another. I'm not sure if anyone has other ideas? Maybe Context could be BuildRunner, to emphasize that it handles the actual process of running the build?

I honestly don't know enough about BuildContext or CompileContext to say what they should be named, but I did think it was odd how similar their names were. I am happy to name things whatever.

[weihanglo]

It might be a bit odd if cargo tree requires BuildRunner but doesn't really build stuff. I am not sure though.

[ehuss]

It might be a bit odd if cargo tree requires BuildRunner but doesn't really build stuff. I am not sure though.

Maybe I'm a little confused, I don't think cargo tree uses either of the contexts?

Or maybe my previous message wasn't clear. I was referring to the old Context, not the old Config.

[weihanglo]

Thanks for the clarification, Eric. Then BuildRunner makes sense to me!

[bors]

☔ The latest upstream changes (presumably #12861) made this pull request unmergeable. Please resolve the merge conflicts.

[weihanglo]

Finished the review! Thanks for the hard work 👍🏾

There might be some other places need updates, but let's get this merged asap to avoid conflicts.

[epage]

If there is anything else, we can patch it up over time

@bors r+

[bors]

📌 Commit 42c645a has been approved by epage

It is now in the queue for this repository.

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout rename-config (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self rename-config --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging src/cargo/util/toml_mut/dependency.rs
Auto-merging src/cargo/sources/git/utils.rs
Auto-merging src/cargo/ops/registry/mod.rs
Auto-merging src/cargo/ops/fix.rs
Auto-merging src/bin/cargo/main.rs
CONFLICT (content): Merge conflict in src/bin/cargo/main.rs
Auto-merging src/bin/cargo/commands/help.rs
CONFLICT (content): Merge conflict in src/bin/cargo/commands/help.rs
Auto-merging src/bin/cargo/cli.rs
CONFLICT (content): Merge conflict in src/bin/cargo/cli.rs
Auto-merging crates/resolver-tests/src/lib.rs
Automatic merge failed; fix conflicts and then commit the result.

[epage]

@bors r+

[bors]

📌 Commit 118afd0 has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit 118afd0 with merge 762c7d8...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing 762c7d8 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing 762c7d8 to master...

[bors]

👀 Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request.