[feature/dataflow] Add a pre-pass to scan type name strings in the app #1079
Comments
10 tasks
12 tasks
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Nov 4, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Dec 2, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Dec 3, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Dec 7, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Dec 9, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Dec 10, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Dec 14, 2020
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Jan 4, 2021
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Jan 15, 2021
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
sbomer
added a commit
to sbomer/linker
that referenced
this issue
Jan 20, 2021
This introduces the ability to add assemblies to LinkContext lazily and have them processed in MarkStep. For now, the only additional processing is to load references and run the TypeMap logic. Later, embedded XML processing and constant propagation will also happen for lazy assemblies. This is Phase 1 outlined in dotnet#1164 (comment). Fixes dotnet#943 Fixes dotnet#1079
|
No longer necessary because with #1666 later steps can pull in new assemblies and they will still get processed correctly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Due to structure of the step architecture in linker, steps that might optionally pull in new assembly dependencies into the closure currently need to run a global pre-pass over the entire app before we reach
MarkStep. This architectural deficiency will have to be fixed at some point, but before we do that, dataflow will also need to run such inefficient global prepass to locate all strings stored into locations marked withDynamicallyAccessedMemebersso that we can potentially add new assemblies into the closure.We should do whatever is the fastest thing. We could potentially do something as dumb as going over all user strings in the assembly, looking for ones that look like a fully qualified type name (have a comma in it and maybe some other heuristics to trim the list of looked at strings down) and try to open the associated assembly, so that we don't need to actually parse IL.
Plus we need to scan custom attributes if their constructor/setter/field is marked DynamicallyAccessed.
The text was updated successfully, but these errors were encountered: