-
Notifications
You must be signed in to change notification settings - Fork 323
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
Exporting non-existing symbols fails with compiler error #7960
Exporting non-existing symbols fails with compiler error #7960
Conversation
…-symbols-should-result-in-an-error # Conflicts: # engine/runtime/src/main/java/org/enso/interpreter/util/ScalaConversions.java
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
ImportExport.apply( | ||
exportedSymbol, | ||
new ImportExport.SymbolDoesNotExist(exportedSymbol.name(), moduleOrTypeName.name()), | ||
ImportExport.apply$default$3(), | ||
ImportExport.apply$default$4() | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes me sad to see this done in not-Scala, but I know this is the general direction. But it still makes me sad 🙁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from some weird perks, like calling methods with default arguments, or methods on objects, there is nothing stopping us from calling Scala stuff from Java stuff anymore. It does not look nice, but it is the most viable compromise for now.
engine/runtime/src/test/scala/org/enso/compiler/test/semantic/ImportExportTest.scala
Show resolved
Hide resolved
@@ -175,7 +175,6 @@ from project.Data.Numbers export Float, Integer, Number | |||
from project.Data.Range.Extensions export all | |||
from project.Data.Statistics export all hiding to_moment_statistic, wrap_java_call, calculate_correlation_statistics, calculate_spearman_rank, calculate_correlation_statistics_matrix, compute_fold, empty_value, is_valid | |||
from project.Data.Text.Extensions export all | |||
from project.Data.Time.Conversions export all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file does not exist, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep.
It's my fault, I forgot to remove this export after removing the file, sorry.
Thanks for adding a pass that catches such errors! ❤️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly. This is why it is now removed - the compilation now fails with this pass.
…-symbols-should-result-in-an-error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice to see we detected an error in standard library.
private UUID uuid; | ||
|
||
private PrivateModuleAnalysis() {} | ||
|
||
public static PrivateModuleAnalysis getInstance() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't getter better than a field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In most scenarios, I would say so. But here, I wanted to get as closest to scalac
as possible - which creates $MODULE$
public static final field for object
. Just my preference. I could refactor it to getter once more.
engine/runtime/src/main/java/org/enso/compiler/pass/analyse/ExportSymbolAnalysis.java
Outdated
Show resolved
Hide resolved
engine/runtime/src/main/java/org/enso/compiler/pass/analyse/ExportSymbolAnalysis.java
Outdated
Show resolved
Hide resolved
…d-result-in-an-error' of github.com:enso-org/enso into wip/akirathan/7867-Exporting-non-existing-symbols-should-result-in-an-error
…-symbols-should-result-in-an-error
Pavel Marek reports a new STANDUP for yesterday (2023-10-05): Progress: - Finalizing the PR
|
…-symbols-should-result-in-an-error
Closes #7867
Pull Request Description
Adds a new compiler analysis pass that ensures that all the symbols exported via
export ...
orfrom ... export ...
statements exist. If not, generates an IR Error.Important Notes
We already have such a compiler pass for the version with imports in ImportSymbolAnalysis.scala
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
./run ide build
.