Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Fix 21544 - -checkaction=context formats enum members as their base type #3336

Merged
merged 1 commit into from Jan 25, 2021

Conversation

MoonlightSentinel
Copy link
Contributor

Generate code that detects the correct enum member (or defaults to the base type in case of an invalid enum value).

@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @MoonlightSentinel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close Bugzilla Severity Description
21544 minor -checkaction=context formats enum members as their base type

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + druntime#3336"

@dlang-bot dlang-bot added the Bug Fix Include reference to corresponding bugzilla issue label Jan 21, 2021
}

// Format invalid enum values as their base type
return "cast(" ~ V.stringof ~ ") " ~ miniFormat(*(cast(BaseType*) &v));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this allocate ? Also miniFormat!BaseType(v) should work, no ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this allocate ?

Yes, but string concatenation is used in several places. But I could also re-use combine here...

Also miniFormat!BaseType(v) should work, no ?

No because miniFormat's accepts it's parameter by ref

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but string concatenation is used in several places.

If we are to make this the default, assert(a != b) should not allocate.
Note that it currently does anyway, because of throw new AssertError, but it really shouldn't, because that makes it unusable in destructors.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess this could use combine (or some other utility method) s.t. we can change the allocation strategy in the future.

But that will always be a problem for a user-defined toString()s that are not @nogc (unless those are skipped while running destructors)

Copy link
Member

@schveiguy schveiguy Jan 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assert errors shouldn't really be caught. Can we just malloc it?

Yes, a bit of a sloppy solution. But likely the program is about to end.

Copy link
Member

@schveiguy schveiguy Jan 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another solution -- set up a "for asserts" allocator that uses malloc, and then frees everything just before the program exits.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that will always be a problem for a user-defined toString()s that are not @nogc (unless those are skipped while running destructors)

that's going to be a really tough problem to solve.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just malloc it?

hah, just looked at what combine does, and it does just that ;) That's the solution right there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Maybe miniFormat should be reworked to use an OutputRange-like buffer s.t. it doesn't need to reallocate to build the final string.

Generate code that detects the correct enum member (or defaults to the
base type in case of an invalid enum value).
Copy link
Member

@Geod24 Geod24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a question, LGTM


// Invalid enum value is printed as their implicit base type (int)
e = cast(E) 3;
assert(miniFormat(e) == "cast(E) 3");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the two spaces ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

combine inserts a space before and after the token (here "")

@RazvanN7 RazvanN7 merged commit c1a3fe3 into dlang:master Jan 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Fix Include reference to corresponding bugzilla issue
Projects
None yet
5 participants