Take the latest tool-base and bring a handful of improvements#316
Take the latest tool-base and bring a handful of improvements#316yevhenii-nadtochii merged 11 commits intomasterfrom
tool-base and bring a handful of improvements#316Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #316 +/- ##
============================================
+ Coverage 76.46% 76.57% +0.10%
- Complexity 550 551 +1
============================================
Files 186 186
Lines 4105 4107 +2
Branches 380 378 -2
============================================
+ Hits 3139 3145 +6
+ Misses 835 834 -1
+ Partials 131 128 -3 |
yevhenii-nadtochii
changed the title
tool-base and bring a handful of small improvementstool-base and bring a handful of improvements
|
@yevhenii-nadtochii The reason for returning 255 and not 1 is exactly the commonality of the latter. We want to distinguish the case in which we made a deliberate choice to stop the machine and the cases in which some third-party code (or JVM itself) has exited due to their particular reasons. |
armiol
left a comment
armiol
left a comment
There was a problem hiding this comment.
@yevhenii-nadtochii LGTM except for the exit code change.
| * Obtains a [FieldAccess] to the [field] of this message. | ||
| */ | ||
| public fun Expression<out Message>.field(field: Field): FieldAccess = | ||
| public fun Expression<Message>.field(field: Field): FieldAccess = |
There was a problem hiding this comment.
As long as it allows you to use this code in Validation, looks logical.
| e.printStackTrace(this) | ||
| println("```") | ||
| } | ||
| exitProcess(-1) |
There was a problem hiding this comment.
See my comment on the PR level.
|
@armiol PTAL |
3 participants
This PR does the following:
tool-baseto pick up tool-base #111.Expressionhierarchy covariant. Previously, only some child members declared it.FieldDeclarationis actuallyStatement.Remove nullability of
MemberpropertiesI'm not 100% sure about this change, but personally don't foresee any problems.
I suggest moving null safety checks from the usage site to the declaration site of
Member.contextandtypeSystemproperties. Making them non-nullable is desired for the following reasons:JavaRendererthat has such a linepublic fun typeSystem(): TypeSystem = typeSystem!!.!!leads to a naked NPE while ISE from the declaration site would bring an error message.select()method inMember, and it just throws when used without the injected codegen context, but could have returnednullas properties do.