Skip to content

[NFC] Enforce use of Type:: on type names #2434

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

Merged
merged 7 commits into from
Jan 7, 2020

Conversation

tlively
Copy link
Member

@tlively tlively commented Nov 13, 2019

There's some test failure in this change even though it is supposed to be nonfunctional. But before I fix that I thought I would see if this is even a change people are interested in making.

Please don't spend time going through this methodically right now. Just initial impressions would be good.

@aheejin
Copy link
Member

aheejin commented Nov 13, 2019

I prefer this over #2433. Enforcing use of Type:: is clearer and has less risk of clashing, and we don't need something like constexpr Type none = Type::none; anymore.

@kripken
Copy link
Member

kripken commented Nov 13, 2019

How does this related to #2433? Do we need just one of the two?

src/wasm-type.h Outdated
// is different, as it can be "ignored" when doing type checking across
// branches
unreachable
class Type {
Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't just switching to enum class get you most of the benefits?

@tlively
Copy link
Member Author

tlively commented Nov 13, 2019

This PR builds on #2433 and includes it as the first commit. It's a shame that GitHub doesn't support stacked PRs. @sbc100 enum class wouldn't work because we need to to be a class to support multivalue, see #2433.

@sbc100
Copy link
Member

sbc100 commented Nov 13, 2019

Perhaps switching to enum class first, which would keep 99% of this change the same might work then? That was you can do a followup proposal to make it into an actual class it might be easier to review (since it would eliminate a lot of the noise from the this change)? Just a thought.

@tlively
Copy link
Member Author

tlively commented Nov 13, 2019

I was hoping to get #2433 merged first, which is a small PR that should be easy to review. Then I would rebase this PR on top of that.

@sbc100
Copy link
Member

sbc100 commented Nov 13, 2019

Ah yes, that makes sense. Sorry for the noise.

As the number of types and the length of their names grow, it becomes
less and less desirable to have them in the global wasm
namespace. This PR removes the global constexprs that mirror the value
type enum elements inside the `Type` class to enforce the use of the
`Type::` prefix everywhere the value types are used directly.
@tlively
Copy link
Member Author

tlively commented Nov 13, 2019

I still have to go through this and reformat comments, but when that is done this will be ready for review.

@tlively tlively marked this pull request as ready for review November 13, 2019 23:05
@aheejin aheejin mentioned this pull request Dec 9, 2019
@tlively
Copy link
Member Author

tlively commented Jan 7, 2020

Now that all the large-scale refactorings have settled down, I believe this is a good time to get this change in @kripken @aheejin.

Copy link
Member Author

@tlively tlively left a comment

Choose a reason for hiding this comment

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

I have audited all of the files for comment formatting issues and they have all been resolved.

Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

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

Does this affect #2572?

constexpr Type nullref = Type::nullref;
constexpr Type exnref = Type::exnref;
constexpr Type unreachable = Type::unreachable;

Copy link
Member

Choose a reason for hiding this comment

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

this enforcees that we must use the Type:: notation, is that right?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's correct. I'll follow up separately on #2572; it isn't materially affected by this PR.

@tlively tlively merged commit e8f9d20 into WebAssembly:master Jan 7, 2020
@tlively tlively deleted the namespaced-types branch January 7, 2020 19:16
aheejin added a commit to aheejin/binaryen that referenced this pull request Apr 12, 2020
These seem to be accidentally introduced in when we enforced use of
`Type::` on type names in WebAssembly#2434.

By the way TIL this actually compiles:
```
Type::Type::Type::Type::Type::Type::Type::Type::none
```
aheejin added a commit to aheejin/binaryen that referenced this pull request Apr 12, 2020
These seem to be accidentally introduced in when we enforced use of
`Type::` on type names in WebAssembly#2434.

By the way TIL this actually compiles:
```
Type::Type::Type::Type::Type::Type::Type::Type::none
```
aheejin added a commit to aheejin/binaryen that referenced this pull request Apr 12, 2020
These seem to be accidentally introduced in when we enforced use of
`Type::` on type names in WebAssembly#2434.

By the way TIL this actually compiles, and don't know why:
```
Type::Type::Type::Type::Type::Type::Type::Type::none
```
aheejin added a commit to aheejin/binaryen that referenced this pull request Apr 12, 2020
These seem to be accidentally introduced in when we enforced use of
`Type::` on type names in WebAssembly#2434.

By the way TIL this actually compiles, and don't know why:
```
Type::Type::Type::Type::Type::Type::Type::Type::none
```
aheejin added a commit that referenced this pull request Apr 12, 2020
These seem to be accidentally introduced in when we enforced use of
`Type::` on type names in #2434.

By the way TIL this actually compiles, and don't know why:
```
Type::Type::Type::Type::Type::Type::Type::Type::none
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants