[ILVerify] Implement verification of initonly fields#4914
[ILVerify] Implement verification of initonly fields#4914jkotas merged 2 commits intodotnet:masterfrom Dynatrace:initOnlyField
Conversation
| instance = null; | ||
|
|
||
| if (field.IsInitOnly) | ||
| Check(_method.IsStaticConstructor && field.OwningType == _method.OwningType, VerifierError.Initonly); |
There was a problem hiding this comment.
Nit - change the casing of VerifierError.Initonly to VerifierError.InitOnly to match the property name?
| //E_ADDR_BYREF "Address of not allowed for ByRef." | ||
| //E_ADDR_LITERAL "Address of not allowed for literal field." | ||
| //E_INITONLY "Cannot change initonly field outside its .ctor." | ||
| Initonly, // Cannot change initonly field outside its .ctor. |
There was a problem hiding this comment.
@jkotas @ArztSamuel
Is this file the list of all checks/erros implemented by PEVerify, where all the uncommented ones have been implemented by ILVerify so far?
FYI @VSadov
There was a problem hiding this comment.
Yes, that is correct.
There are some errors that were added with ILVerify and a lot of commented errors early in the list are metadata related (as opposed to IL related).
There was a problem hiding this comment.
Is the intention for ILVerify to only verify IL errors, or are metadata errors in scope too? Does it current enforce any metadata rules?
There was a problem hiding this comment.
ILVerify does basic metadata validation as side-effect of reading the metadata and building the types out of it.
I do not see a reason why we would not want to add more in-depth metadata validation/verification to ILVerify.
There was a problem hiding this comment.
I do not see a reason why we would not want to add more in-depth metadata validation/verification to ILVerify.
Yes, I agree. I simply concentrated on IL verifications for now, since basic metadata validation is done as a side-effect anyway, as you mentioned.
As described in
ECMA II.16.1.2 Field contract attributes, initonly fields should only be mutable in their corresponding constructor. This implements this rule.As mentioned in #4911 and noted in ECMA, a
ldfldaof an initonly field should always be unverifiable. However, PEVerify does not report an error for ldflda instructions in ctors. I was not sure how to deal with this case for ILVerify and have stuck to the way PEVerify does it for now, since this rule should be revisited after the proposed spec changes anyway.This fixes #4911.