-
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
SuggestionBuilder needs to send ascribedType of constructor parameters #6655
SuggestionBuilder needs to send ascribedType of constructor parameters #6655
Conversation
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.
Much more Scala-like changes! I assume you will need the same changes as I did overall the code base. Plus you need support for type arguments in constructor - I solved it by adding resolveType
additional parameter with type parameter names.
@@ -4723,6 +4722,7 @@ object IR { | |||
def mapExpressions(fn: Expression => Expression): Specified = { | |||
copy( | |||
name = name.mapExpressions(fn), | |||
ascribedType = ascribedType.map(fn), |
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.
I guess this change of IR.DefinitionArgument.Specified.mapExpressions
is answering my question:
I was hoping the
d.mapExpressions(resolveExpression ...)
will iterate overIR.DefinitionArgument
, but it doesn't.
Overall the changes in this PR look more Scala-like than my #6584
engine/runtime/src/main/scala/org/enso/compiler/pass/resolve/TypeNames.scala
Outdated
Show resolved
Hide resolved
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.
I'm missing some tests in TypeSignaturesTest
since this change touches that pass. But overall, looks sane.
private def buildArgument(arg: IR.DefinitionArgument): Suggestion.Argument = { | ||
val signatureOpt = arg.name.getMetadata(TypeSignatures).map { meta => | ||
buildTypeSignature(meta.signature) match { | ||
case Vector(targ) => buildTypeArgumentName(targ) |
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 seems to assume that you don't deal with Function
, which can return vector of size > 1?
private def resolveDefinitionData( | ||
data: IR.Module.Scope.Definition.Data | ||
): IR.Module.Scope.Definition.Data = { | ||
data.copy( |
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.
We should eventually start using a smarter copy
that only copies if data.arguments.map(resolvedArgument) != data.arguments
. But that optimization can be done in multiple places so can be done later.
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.
Am I right that transformExpressions
does such kind of optimization a bit? My understanding is that transformExpression
callback may specify partial match
on just a few IR.Expression.SubTypes
and only those get duplicated - the rest of the IR
tree remains unchanged.
Shall we prefer the use of transformExpressions
over copy
? Are there any places to perform such a replacement in current code?
start using a smarter copy
Is there such a "smarter copy" already or do we have to write one? Can we create such "no-copy-if-unmodified" copy
in a generic way or do we have to manually override each copy
implementation or wrap each copy
invocation?
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.
Tests look good. I guess a negative test with unknown type could be nice, but if it's already handled by @JaroslavTulach 's PR I guess it's also fine to skip it.
PR enables the resolution of qualified names in type signatures. At this moment stdlib compilation fails with two errors:
|
An attempt to import Java inner class! Mitigated in 74c6f99 and reported #6678
Same problem as in my PR - addressed by e56bb3a Let's see how far the CI can get... |
11bf895
to
74c6f99
Compare
3d73eb7 addresses this failure. |
@@ -1,5 +1,6 @@ | |||
from Standard.Base import all | |||
import Standard.Base.Errors.Illegal_Argument.Illegal_Argument | |||
import Standard.Database.Data.SQL_Type.SQL_Type |
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 makes Standard.Table
library dependent on Standard.Database
. I'm not sure if we want that because the Database lib already depends on the Table
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 fact, this caused an issue with IR caching https://github.com/enso-org/enso/actions/runs/4966001323/jobs/8887184345#step:10:3121
What happened is that IR for Standard.Database.Connection.Database
module was not cached, and it resulted in compilation error:
INFO ide_ci::program::command: bashℹ️ In module Standard.Database.Connection.Database:
INFO ide_ci::program::command: bashℹ️ Compiler encountered errors:
INFO ide_ci::program::command: bashℹ️ Database.enso[23:11-23:28]: The name `Connection_Details` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[23:33-23:50]: The name `Connection_Options` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[23:55-23:64]: The name `Connection` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[23:68-23:76]: The name `SQL_Error` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[24:25-24:42]: The name `Connection_Options` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[28:29-28:41]: The name `Single_Choice` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[30:28-30:33]: The name `Vector` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[31:63-31:67]: The name `False` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[35:9-35:14]: The name `Option` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[36:5-36:17]: The name `Single_Choice` could not be found.
INFO ide_ci::program::command: bashℹ️ Database.enso[36:27-36:33]: The name `Display` could not be found.
INFO ide_ci::program::command: bash⚠️ Aborting due to 11 errors and 0 warnings.
INFO ide_ci::program::command: bashℹ️ Execution finished with an error: Compilation aborted due to 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.
This makes Standard.Table library dependent on Standard.Database
Cyclic dependencies are bad. It'd be good to prevent them with some failure - #6679
In fact, this caused the issue with IR caching
Oh, my dear! I was hunting the problem for almost a week and it is caused by such a little oversight. Thank you very much for working on this PR in parallel with #6584 - it was very refreshing and useful to see different approach to the problem. Without your help I'd still be blindly searching for a bug in BindingsMap
.
I can reproduce the issue with IR caches that fails the CI:
there's no issues when run with |
Merging it to unblock @JaroslavTulach |
…z-6260 * develop: Build nightlies every day. (#6681) Force `newDashboard` default on the CI-built packages. (#6680) Verify ascribed types of parameters really exist (#6584) SuggestionBuilder needs to send ascribedType of constructor parameters (#6655) Improvements to the Table visualization. (#6653) Removing flush (#6670) Improving widgets for take/drop (#6641)
I'm guessing this was the circular dependency thing because I have no issues right. And yes, I'm able to reproduce the problems when I introduce that import. |
* develop: Build nightlies every day. (#6681) Force `newDashboard` default on the CI-built packages. (#6680) Verify ascribed types of parameters really exist (#6584) SuggestionBuilder needs to send ascribedType of constructor parameters (#6655) Improvements to the Table visualization. (#6653) Removing flush (#6670) Improving widgets for take/drop (#6641) disable authentication and newDashboard by default (#6664) Add COOP+COEP+CORP headers (#6646)
Pull Request Description
close #6611
Changelog:
ascribedType
field of the constructor argumentsascribedType
Important Notes
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.