Should there be a flag to turn off the implicit module warning? about chapel HOT 4 OPEN

That seems attractive. I assume --no-warnings would quiet it today? (realizing that's a big hammer, so I don't think it's the answer).

Yup, it does

I think of us still having an outstanding design question about how, in Dyno, we'd want to squash warnings, dial errors down to warnings, warnings up to errors, etc. where one approach would be to do some sort of naming/numbering of warnings and to make the flags operate on those (what I think of as "icc"- or "cce"-style). But another would be to just continue investing in our current "warning flag per family of warnings" approach, which seems to be the way gcc has gone? Only mentioning it here because for a low-priority case like this, it might be more valuable to spend effort on wrestling with that design question and implementing it there (though even that design question isn't particularly high priority for me at the moment).

Yeah, I think keeping categorization in mind seems like a nice way of addressing it faster than it would be on its own (but agree that I wouldn't view it as high priority even then unless we realized there were quite a lot of warnings that fell into the same category)

from chapel.

That seems attractive. I assume --no-warnings would quiet it today? (realizing that's a big hammer, so I don't think it's the answer).

I think of us still having an outstanding design question about how, in Dyno, we'd want to squash warnings, dial errors down to warnings, warnings up to errors, etc. where one approach would be to do some sort of naming/numbering of warnings and to make the flags operate on those (what I think of as "icc"- or "cce"-style). But another would be to just continue investing in our current "warning flag per family of warnings" approach, which seems to be the way gcc has gone? Only mentioning it here because for a low-priority case like this, it might be more valuable to spend effort on wrestling with that design question and implementing it there (though even that design question isn't particularly high priority for me at the moment).

from chapel.

@lydia-duncan : One other thought here: We could potentially squash this warning in cases that seem sufficiently non-library like / non-confused, like:

proc main() {
  use M;
  ...
}

module M {
  ...
}

I could imagine an argument that generating the warning for a "main module" like this is overkill since it seems obvious the user is writing module-scope code that will start running the program.

from chapel.

Potentially, though I think trying to guess what the user intended has diminishing returns after a certain point.

from chapel.