Repository navigation
Use the scoped keyword in LibraryImportGenerator - #73479
Conversation
|
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsUse the scoped keyword to significantly simplify the caller-allocated-buffer logic for stateful marshallers while also increasing safety/keeping us from shooting ourselves in the foot with lifetimes. This is in draft until we can update the version of Roslyn we build the generator against to Roslyn 4.4 as that version guarantees the existence of the scoped keyword.
|
66d6de2 to
a18f406
Compare
|
Closing and reopening to retrigger all legs now that packages have been mirrored |
|
/azp run dotnet-linker-tests, runtime, runtime-dev-innerloop, runtime-staging |
|
Azure Pipelines successfully started running 4 pipeline(s). |
fa4758a to
2f1bd69
Compare
2f1bd69 to
95f64c6
Compare
95f64c6 to
33829ed
Compare
|
Would it make sense to separate out the version upgrade from actually using the scoped keyword in LibraryImportGenerator at this point? It seems like (fallout from) the version upgrade has gotten more involved and become the bulk of this change now, so it might be nice to keep them separate. |
|
I was thinking about that... I'll spin it out to another PR once I get CI green (so I don't need to iterate on it much). |
0e97d34 to
fde75aa
Compare
fde75aa to
243df5b
Compare
|
Moved the code-style changes to #74445. @elinor-fung can I get another quick review look? |
…-buffer logic for stateful marshallers while also increasing safety/keeping us from shooting ourselves in the foot with lifetimes. PR feedback Use the official ScopedKeyword API
243df5b to
d12d883
Compare
|
Failure is slow macs and #73688. Merging |
Use the scoped keyword to significantly simplify the caller-allocated-buffer logic for stateful marshallers while also increasing safety/keeping us from shooting ourselves in the foot with lifetimes.
This PR also updates all of the in-box generators to build against 4.4 and fixes any build errors that were encountered as part of that process.