test: reproduce the issue with the cstr parsing inside a the proc macro

[vincenzopalazzo]

While I am working on trying to patch #112820

I think it is useful to have a test for this case as known-bug

[rustbot]

r? @WaffleLapkin

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

[WaffleLapkin]

sure

[WaffleLapkin]

@bors r+ rollup

[bors]

📌 Commit 0a8139e has been approved by WaffleLapkin

It is now in the queue for this repository.

[compiler-errors]

Shouldn't this test be asserting that c"" formats like c""?

Also, I have no idea why this needs to be committed as a separate test. The fix should be a minor fix to the proc macro library to handle cstrings correctly.

[compiler-errors]

@bors r-

please fix the test so that it will eventually work when c"" gets formatted correctly

[vincenzopalazzo]

please fix the test so that it will eventually work when c"" gets formatted correctly

Thanks @compiler-errors for the catch! I push the correct version now.

Also, I have no idea why this needs to be committed as a separate test. The fix should be a minor fix to the proc macro library to handle cstrings correctly.

Currently macros have a working group and this issue should be discussed before inside the wg and then patched as you suggested. All the macros change will require at least one review from the wg due to that claim that we did inside the MCP.

Due to the original issue, there was some attempt (maybe) to solve the issue with cstr (See #112820 (comment)) I wrote a test to confirm it. Now this may be not useful, but IMHO it will be for the next person who will patch this issue and will find the test.

As a plus, this commit will be here anyway due the patch should include the UI test.

r? @compiler-errors

[WaffleLapkin]

@vincenzopalazzo I went ahead and opened a fix for the issue: #116124. Sorry for taking an issue you've been working on, but it looked like you did not made progress since June, while the issue is easy to fix, so it seemed better to just fix it right away. In general, please remove your assignment or ask for help if you are struggling to fix an issue. This way the issue won't be stalling — either you'll get help and be able to make progress, or someone else will take a stab at fixing it.

[vincenzopalazzo]

I need to apologize to @compiler-errors for saying the following statement and everyone that understand tha I wanted to impose my review of one review of the wg on each PR

Currently macros have a working group and this issue should be discussed before inside the wg and then patched as you suggested. All the macros change will require at least one review from the wg due to that claim that we did inside the MCP.

In my message, I used the term required drawing a parallel to how the diagnostic working group is consulted for every change in their subsystem (though it might not be a perfect comparison, as I don't think there's an example quite like the macros working group). They can voice their opinions on changes. If they feel the need to reject a change, they can discuss it directly in the PR. That was my original intent behind using the word "required". It seems I might have chosen an imprecise term.

---

In addition due that I am mentioned the MCP, the MCP statement that I am referring to is:

An important role for the WG is to bootstrap the experience necessary to make deeper changes to the macro system and to review changes to the PR system.

To me, this suggests that, at a minimum, we should be notified within the PR to review it. This offers us the opportunities to:

• Share the working group's perspective on the PR.
• If the PR is crafted by someone well-versed (not just in the Rust compiler but in the broader domain), we can learn from their expertise. Such interactions would be valuable in building our experience and also do not solve the current problem that the compiler has with the macros work.

To clarify, my main point was simply that our working group serves as a hub for individuals eager to work on this aspect of the compiler, especially when there's limited interest or availability from others. I never intended to present our group as the sole experts, but merely as dedicated contributors.

This might seem evident, but it underscores why we are a working group and not an independent team. We aim to operate under the guidance of the t-compiler, hoping that our efforts, past and future, on the macros subsystem won't go unnoticed.

---

thanks @WaffleLapkin for the patch, I had a similar version on https://git.hedwing.dev/vincenzopalazzo/rust Happy that we converge on it