Related to #9165 work. Let's make sure the current behavior of `if`/`then`/`else` is properly tested by a unit test. Extracting test created as part of #11365 to verify it really describes the current behavior.
1. Bumped eslint and its plugins versions, and autofix new errors (mostly eslint disables which were no longer neccessary)
2. ~~Replace eslint with eslint-p which speed up linter a bit (at least on my machine)~~ - CI machines don't like it.
3. Fixed/worked around one problem with flacky selection _unit_ tests.
Improves the speed of `ExecutionEnvironment.hasContextEnabled`.
# Important Notes
Local speedup of `Map_Error_Benchmark_Vector_ignore.Map_Id_All_Errors` benchmark is roughly ???.
Move annotations into fields of Function and ConstructorDefinition.
# Important Notes
New syntax: Constructor argument-definition lines
- Each argument in a type-constructor definition may be specified on its own (indented) line.
Relaxed syntax: Unparenthesized arguments to annotations
- A generic annotation now uses the rest of the line as its argument expression; the expression no longer needs to be parenthesized.
Check if the provided argument is really a string. Shields against:
```
java.lang.ClassCastException: class org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj cannot be cast to class java.lang.String (org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj is in unnamed module of loader org.netbeans.StandardModule$OneModuleClassLoader @2415a13c; java.lang.String is in module java.base of loader 'bootstrap')
at org.enso.tools.enso4igv.EnsoRootProject$LogicalView.findPath(EnsoRootProject.java:74)
at org.netbeans.modules.project.ui.ProjectsRootNode.findNode(ProjectsRootNode.java:185)
at org.netbeans.modules.project.ui.ProjectTab$2.run(ProjectTab.java:552)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018)
Caused: org.openide.util.RequestProcessor$SlowItem
```
looks like the `findPath` argument doesn't have to be `String` as previously (and too optimistically) expected by the code.
Eliminate `private` modifier-node: `private` is a field in supporting types, or a single-token node in the case of `private` declarations.
# Important Notes
- Rust parser tests: Switch to a builder-style API for defining expected `Function` ASTs to allow further changes to `Function` fields without rewriting all the tests again.
- TreeToIr: Fix discarded module-level `diag`; add a test that covers module diagnostics.
- Syntax: Disallow `private` methods in function blocks. (Previously this was enforced in the compiler.)
- Close https://github.com/enso-org/cloud-v2/issues/1492
- Use multiplart upload for large files (>6MB)
- Split file into chunks of *exactly* 10MB (backend currently returns a fixed number of chunks)
- Call "start upload", then upload each chunk to S3 (currently sequentially), then "end upload"
- Files <=6MB (lambda limit) still use the current endpoint
# Important Notes
None
- ⚠️ Follow up to #11219. MUST NOT be merged in before that PR.
- Changes:
- Add optional overlay to `Popover`s
- Add and use `useAssetPassiveListener` everywhere to get reactive updates to asset state even outside Asset Panel
- `setItem` has been removed in favor of simply waiting for invalidations
- Migrate more `Modal`s to `Popover`s
- Migrate more inputs to `Form`s
- Periodically refetch Datalink in Asset Panel
- Show optimistic state for asset description (adding this because it is trivial to add)
- Remove usages of `get*` as mutations throughout the entire codebase - replace with `fetchQuery`
- Fixes most of rest of https://github.com/enso-org/cloud-v2/issues/1529
- (1) ℹ️ fixed in #11219
- (2) ❌ backend issue
- (3) ❌ out of scope
- (4) ❌ backend issue
- (5) ❌ out of scope
- (6) ❌ [wontfix]? i think this is intentional, it's not so much slow scrolling and moreso snapped scrolling
- (7) ❌ backend issue
- (8) ℹ️ fixed in #11126
- (9) ❌ out of scope (potentially requires a way to trigger a tooltip on a disabled button)
- (10) ❌ (will check later) Make sure you are not able to open a project opened by another user: cmd + click is not always working.
- (11) Drag from team space to user space should copy asset
- (12) ❌ (will check later) Drag from user space to team should move (and swap ownership)
- (13) ℹ️ fixed in #11219
- (14) ℹ️ fixed somewhere (?)
- (15) ℹ️ fixed somewhere (?)
- (16) Show correct (and up-to-date) description for projects
- (17) ℹ️ fixed in #11219
- (18) ℹ️ fixed in #11219
- Fix https://github.com/enso-org/cloud-v2/issues/1535
- Completely remove optimistic UI for "copy asset"
- Fix https://github.com/enso-org/cloud-v2/issues/1541
- Make selection brush work again
- Unintentionally regressed in 51733ee876 (diff-f3e29bffcda342ab6a9dbafc58dde88ce26638eaecda1f17f40ca7e319c90cc8L89)
# Important Notes
None
* Handle autoscoped constructor args with no UUID
An application involving >1 autoscoped atom constructor arguments
with no ID would lead to a silent type error in GUI. It was silent
because once IdMap gets updated, the original type error disappears and
users are left with a No_Such_Method on a Panic.
The type error may occur because the compiler was inferring the same
UUID for autoscoped constructors. Args with UUID are cached therefore a
type confict might occur on the second (or later) argument.
Added a unit test case demonstrating the problem (previously it would
fail). The search path is now a bit more careful when inferring
arguments.
* One more test
Align `Assignment`/`Function` distinction in AST with compiler's implemented semantics:
- The ambiguous case `funcOrVar = expression` is now parsed as a `Function` when in a `Type` definition or in the top level of a module. I.e. it is an `Assignment` in contexts where the RHS is evaluated immediately when the binding is evaluated, and a `Function` in contexts where the RHS is evaluated each time the bound name is evaluated.
- `Assignment` statements now may only occur in function bodies.
Correcting this distinction lays the groundwork for #11302.
Other changes:
- Fixed incorrect source code locations for negative literals and negated expressions.
# Important Notes
New APIs:
- The parser now exposes a `parse_block` entry point, which allows parsing input lines as if in the body of a function. The previous entry point has been renamed to `parse_module`.
close#11251
Changelog:
- add: `CachePreferences` configuration of the expressions that are marked for caching
- update: Invalidate the `self` keywords in the parent frames on function edit
- update: persistance config
# Important Notes
The demo shows that:
1. The new node created in the collapsed function is highlighted (GUI receives the expression update)
2. When the collapsed function is edited, the nodes in the `main` method are updated correctly
https://github.com/user-attachments/assets/41c406ed-ba76-41c8-9e3f-89ac9ff63c3f
Gets ready for avoiding IR traversal by introducing _mini passes_ as proposed by #10981:
- creates [MiniPassFactory](762045a357) (that extends common `IRProcessingPass`) to transform an `IR` element to another `IR` element
- modifies `PassManager` to recognize such _mini passes_ and treat them in a special way - by using `MiniIRPass.compile`
- `MiniIRPass.compile` is using `IR.mapExpressions` to traverse the `IR` - alternative approach [withNewChildren](1abc70d33c) rejected for now, see _future work_ for details
- unlike _mega passes_ `IRMiniPass.compile` **does not recursively** traverse, but with 0964711ba9 it invokes each _mini pass_ at constant stack depth - way better for profiling
- `MiniIRPass.prepare` _works on edges_ since ffd27dfe9b - there is `IRMiniPass prepare(parent, child)` to collect information while pre-order traversing from a particular `IR` parent to a particular `IR` child
- `PassManager` rewritten to group _subsequent mini passes_ together by `MiniIRPass.combine` and really and traverse the `IR` just once - done in 2736a76
- converted to _mini pass_: `LambdaShorthandToLambda`, `OperatorToFunction`, `SectionsToBinOp` and `TailCall`
- tested for 1:1 compatibility by [converting original code to test code](f54ba6d162) and _comparing `IR` produced by old and new_ implementations
Numerous times I wasn't sure when running the IDE if I'm running the bundled engine or a development build. Usually this depends on if I launch the standalone IDE or use a development build of project-manager.
Still it's not always obvious, and making sure that your IDE is running the right engine version is very often the first step when debugging issues with e.g. engine changes not showing up properly.
Thus I thought it may be worth to add this method (currently hidden to users in component browser by marking as `PRIVATE`, one has to type it in manually):
![image](https://github.com/user-attachments/assets/13af3df4-49ff-49bb-9b19-601258a8ca02)
I think it should be a helpful tool for debugging.
# Important Notes
- `std-benchmarks/bench`, which is invoked on the CI, is not affected. It still works as expected.
- Updated list of all projects in `enso` aggregate in c1d43b3ebf
Debugger shows only fields of the current atom constructor: (internal members shown in gray, "public" members shown in bold purple)
![image](https://github.com/user-attachments/assets/21815296-c8aa-4ea2-ae7b-6feac78a221f)
(Note that `static_method` is not displayed as a member of `My_Type` - not in scope of this PR)
# Important Notes
The *interop* contract for `Atom` is changed as follows:
- Members are all methods and fields of the current constructor.
- All methods are internal members.
- If the constructor is project-private, fields are internal members.
- All the members are both readable, and invocable.
- Fields are field getters, that is, they are just methods.
- Fields are not invocable
- Constructors and static methods are **not** members of an atom. They should be members of the type.
- Note that methods used to be atom members before #9692
* Ensure wrapper projects are listed in aggregates
Previously, doing clean to deal with weird modularization failures would
have no effect.
* And updated formatting
* More projects
As cherry-picked from https://github.com/enso-org/enso/pull/11321