Private methods demands that

  class A {
    static set #x(_) {}
    get #x() { }
  }

Report a SyntaxError, due to the mismatched use of static .

This Diff added support for issuing this early error, but uses reportRedeclaration to report an error.

It would be nice to issue a slightly more specific error message, because this is an acceptable construction for non-private methods.

For your information, when adding error messages, please consider updating MDN with the added error, as well as the index of these pages in the devtools

Ashwini has been taking a stab at this.

As a curious outsider, just wondering what the status is on this :)

Currently, as far as I know, no one is working on this, if you're interested in exploring!

Sweet, I think I'll do some exploring! Looks like this bug deals with https://test262.report/browse/language/statements/class/private-non-static-getter-static-setter-early-error.js and friends.

I'm thinking the SyntaxError message could be something along the lines of getter and setter for private name #x should either be both static or non static. I should point out that I'm not too familiar with C++ (I'm more of a js person) so it's probably likely that I'll have to do more learning on my own before i can take a stab at this.

Ok, so here's my understanding of what changes were made in https://phabricator.services.mozilla.com/D113138 and what they mean (sorry this is just a rubber duck moment https://en.wikipedia.org/wiki/Rubber_duck_debugging):

• placement is the variable that tracks whether a private field was declared as static or non-static [1]
• we do our normal bookkeeping when placement matches when we have both a getter and a setter [2, line 840]
• when placement mismatches, we report a redeclaration error [2, line 847]. My understanding that return true or return false is a flag for determining whether we continue parsing or bail.
• reportRedeclaration calls errorAt and friends [3,4]. It is unclear to me how errorAt and similar set up handler_ to be a SyntaxParseHandler [5]. ErrorAt bounces around a bunch of places to the the main code that does errors at [6] and seems to put the metadata into an error struct of some sort then calls the correct method. In this case I believe it's error->throwError(cx)
• we then bounce around to [7]. SyntaxErrors are runtime errors so we bounce to a different method.
• we end up in ErrorToException [8]
• I'm going to stop analyzing here since changing Error messages shouldn't require deep knowledge of the error reporting internals

[1] https://searchfox.org/mozilla-central/source/js/src/frontend/NameAnalysisTypes.h#171
[2] https://searchfox.org/mozilla-central/source/js/src/frontend/Parser.cpp#840,843,847
[3] https://searchfox.org/mozilla-central/source/js/src/frontend/Parser.cpp#491
[4] https://searchfox.org/mozilla-central/source/js/src/frontend/ErrorReporter.h#139
[5] https://searchfox.org/mozilla-central/source/js/src/frontend/Parser.h#448
[6] https://searchfox.org/mozilla-central/source/js/src/vm/ErrorReporting.cpp#93
[7] https://searchfox.org/mozilla-central/source/js/src/vm/ErrorReporting.cpp#38
[8] https://searchfox.org/mozilla-central/source/js/src/jsexn.cpp#298

So, I think what I have to do is

1. create a function reportMismatchedPlacement at https://searchfox.org/mozilla-central/source/js/src/frontend/Parser.cpp#491 . I can use existing code for inspiration
2. create a new message definition here: https://searchfox.org/mozilla-central/source/js/public/friend/ErrorNumbers.msg#84
3. maybe create an error message page: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors ? [question: does this error warrant creating one?]
4. profit!

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

I'd like to pick up this bug. I have a patch incoming building off of George's changes and implementing Matthew's suggestions.

https://hg.mozilla.org/mozilla-central/rev/3f812987146c