JetBrains / JetBrains/resharper-unity

Debugger extension should work better with "Allow property evaluation"

Open
#2,070 0 comments 0 reactions 1 assignee Claimed by @citizenmatt View on GitHub
debugger
Dominant language
C#
Stars
1.2k
Forks
142
PR merge metrics
No merged PRs in 30d

Description

The debugger displays objects in two steps. First it gets value entities/references, and then it gets a value presentation. The entities are references, and do not contain the evaluated value - it could be a field, property or instance method reference. The presentation step will evaluate the reference and return a presentation value. If "Allow property evaluation…" is disabled, the reference is not evaluated and the presentation value will include a "Refresh" link that will force evaluation.

The debugger will override the "Allow property evaluation…" option when getting entities/references. This is so that any evaluation required to retrieve children can be performed, e.g. the "Results" node of `IEnumerable` needs to evaluate the enumerable (into a collection of references). This is fine for the Children and Game Objects nodes in `Component`, `Game Object` and `Scene`, as these groups, and the children are lazily evaluated when opened, similar to the "Results" node. Evaluation is always allowed at this point so there are no problems. The same is true for the custom field sets shown in `SerializeProperty` - we have to evaluate the `propertyType` property in order to know what fields should be shown or filtered.

The "Active Scene", "this.gameObject" and "Scene Path" additional values should be returned as value references. This will show the items in the watch window, but correctly show them as un-evaluated, with a Refresh link.

Currently, the eager evaluation means that any exceptions can be silently ignored. E.g. calling `GetActiveScene()` in a `MonoBehaviour` constructor is invalid and will throw a `UnityException`, which can be silently handled and the "Active Scene" value not shown. If evaluation is going to be lazy, we will probably lose this this, and have to show an error message to the user instead. If it's possible to check if an API can be called from the current location, this should be done when creating the references.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.