Skip to content

Conversation

@jonmeow
Copy link
Contributor

@jonmeow jonmeow commented Feb 3, 2025

Although migration tooling is intended for Carbon, this tooling was primarily a proof-of-concept prototype. The last time it got significant work was in 2022 (https://github.com/carbon-language/carbon-lang/commits/trunk/migrate_cpp); since then, we've mainly been doing small cleanups to keep it building. We're now hitting an issue in #4886 that TypeNodes.inc isn't exposed as a #include.

We already had thoughts about rewriting this as a RecursiveASTVisitor, per rewriter.cpp/rewriter.h. That may justify a significantly different approach than had been set up in cpp_refactoring. But, it's hard to tell.

Either way, my sense is that rather than incrementally trying to keep this code building, we should revisit it when we're ready and have a long-term strategy for how migration should work.

@josh11b josh11b added this pull request to the merge queue Feb 3, 2025
Merged via the queue into carbon-language:trunk with commit a8aca3c Feb 3, 2025
10 checks passed
@jonmeow jonmeow deleted the rm-migrate branch February 3, 2025 22:21
github-merge-queue bot pushed a commit that referenced this pull request Feb 4, 2025
- The actual reason I started this: minor lowering updates in the golden
LLVM IR
- Process.inc changed enough to need a patch context update.
- llvm/llvm-project#123126 added `proto_library`
uses without a `load`, which is broken in bazel 8
- Just commenting these out because we don't use them. I'll follow up
separately about a possible fix, but continuing to use `WORKSPACE` is a
bigger issue LLVM probably should address.
- Note this update is also triggering removal of `migrate_cpp`, in #4887
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants