Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dismantle Decl a little bit more #20424

Merged
merged 2 commits into from
Jun 26, 2024
Merged

Conversation

mlugg
Copy link
Member

@mlugg mlugg commented Jun 26, 2024

This was going to be a bigger branch, but I accidentally regressed stack traces in my previous PR (sorry folks!) and this fixes it. Should be a pretty simple merge. The second commit here is a nop, just a rename I already had done.

The return 0; // TODO in Decl.navSrcLine might look sus, but rest assured the old logic was screwed, and no contemporary debugger uses the source line in this context as far as I'm aware, so making it screwed in a different way is fine for now.

Line numbers for container-level declarations are no longer relative, because there is no advantage to this. Previously, they were relative, and Decl stored the computed absolute number -- this was objectively worse, as we still had the problem of having to update all those absolute numbers, but we were using an extra 4 bytes per Decl. With this system, we can track changes in line numbers more directly, avoiding Decl as a middle man. The only relative line numbers in ZIR now are in dbg_stmt instructions.

This incidentally resolves #20407 -- I'm guessing that a line number was being treated as relative to the wrong thing somewhere. Whatever the issue was, this seems to have solved it!

mlugg added 2 commits June 26, 2024 05:28
We need special logic for updating line numbers anyway, so it's fine to
just use absolute numbers here. This eliminates a field from `Decl`.
This is essentially just a rename. I also changed the representation of
`AnalSubject` to use a `packed struct` rather than a non-exhaustive
enum, but that change is relatively trivial.
@mlugg mlugg requested a review from Snektron as a code owner June 26, 2024 04:39
@mlugg mlugg removed the request for review from Snektron June 26, 2024 04:41
@mlugg
Copy link
Member Author

mlugg commented Jun 26, 2024

@kcbanner, would you be able to confirm that this branch fixes your more complicated repro?

@kcbanner
Copy link
Contributor

@mlugg yep, this change resolves the issue! Thanks for the fix!

@mlugg mlugg merged commit a016ca6 into ziglang:master Jun 26, 2024
10 checks passed
@rofrol
Copy link
Contributor

rofrol commented Jun 26, 2024

AnalSubject? Not a good name.

@mlugg
Copy link
Member Author

mlugg commented Jun 27, 2024

Do you have a better suggestion?

@rofrol
Copy link
Contributor

rofrol commented Jun 27, 2024

AnalysisSubject?

@mlugg
Copy link
Member Author

mlugg commented Jun 27, 2024

Too wordy. (I actually meant to call this AnalUnit, it'll be renamed again in a future commit.)
There's nothing wrong with having a name that, yes, could be considered to have a funny meaning. It wasn't named for that; it's just a good name.

@nektro
Copy link
Contributor

nektro commented Jun 27, 2024

a difference of 4 characters makes it too wordy?

@mlugg
Copy link
Member Author

mlugg commented Jun 27, 2024

With all due respect, I'm not particularly interested in the opinions of general Zig users on the naming of an internal compiler datastructure which has been discussed and agreed upon elsewhere.

@drunderscore
Copy link

With all due respect, your defense of "elsewhere" holds no water unless you actually show where and with who this was discussed and agreed upon.

I have no opinion on this personally, but your cavalier attitude makes me question the accuracy and honesty of the response.

@rohlem
Copy link
Contributor

rohlem commented Jun 27, 2024

your cavalier attitude makes me question the accuracy and honesty of the response.

From what I remember the abbreviation has been joked about between compiler developers when discussing planned changes on the Discord (channel #compiler-devel), so I believe all core members are at least aware of it.

Do you have a better suggestion?

I personally think ana (-> AnaSubject, FnAnaStateProbing, etc., can be pronounced like the name "Anna") is just as understandable, one letter shorter even, and not misreadable as something else.
I don't personally care much to weigh in at this point; if at some point active contributors to the code dislike the name / are uncomfortable with it, then it should be changed obviously.
(Would be nice if we had tooling that makes renaming safe and effortless at that point.)

@drunderscore
Copy link

Thank you for the channel references, I will read through.

I also do not have enough knowledge nor opinion to weigh in (I've certainly seen it used before). I simply found the proposed rationale strangely articulated and thought to express it.

@RieBi
Copy link

RieBi commented Jun 28, 2024

This is hilarious, with all due respect to naming conventions

@codingjoe
Copy link

Just donated for your next pint at the pub. Thank you for keeping programming fun 🫶

@ziglang ziglang locked as off-topic and limited conversation to collaborators Jul 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Regression with source locations in stack traces on Windows
8 participants