|
| 1 | +# Interceptors |
| 2 | + |
| 3 | +## Summary |
| 4 | +[summary]: #summary |
| 5 | + |
| 6 | +*Interceptors* are an experimental compiler feature planned to ship in .NET 8. The feature may be subject to breaking changes or removal in a future release. |
| 7 | + |
| 8 | +An *interceptor* is a method which can declaratively substitute a call to an *interceptable* method with a call to itself at compile time. This substitution occurs by having the interceptor declare the source locations of the calls that it intercepts. This provides a limited facility to change the semantics of existing code by adding new code to a compilation (e.g. in a source generator). |
| 9 | + |
| 10 | +```cs |
| 11 | +using System; |
| 12 | +using System.Runtime.CompilerServices; |
| 13 | + |
| 14 | +var c = new C(); |
| 15 | +c.InterceptableMethod(1); // (L1,C1): prints "interceptor 1" |
| 16 | +c.InterceptableMethod(1); // (L2,C2): prints "other interceptor 1" |
| 17 | +c.InterceptableMethod(2); // (L3,C3): prints "other interceptor 2" |
| 18 | +c.InterceptableMethod(1); // prints "interceptable 1" |
| 19 | +
|
| 20 | +class C |
| 21 | +{ |
| 22 | + public void InterceptableMethod(int param) |
| 23 | + { |
| 24 | + Console.WriteLine($"interceptable {param}"); |
| 25 | + } |
| 26 | +} |
| 27 | + |
| 28 | +// generated code |
| 29 | +static class D |
| 30 | +{ |
| 31 | + [InterceptsLocation("Program.cs", line: /*L1*/, character: /*C1*/)] // refers to the call at (L1, C1) |
| 32 | + public static void InterceptorMethod(this C c, int param) |
| 33 | + { |
| 34 | + Console.WriteLine($"interceptor {param}"); |
| 35 | + } |
| 36 | + |
| 37 | + [InterceptsLocation("Program.cs", line: /*L2*/, character: /*C2*/)] // refers to the call at (L2, C2) |
| 38 | + [InterceptsLocation("Program.cs", line: /*L3*/, character: /*C3*/)] // refers to the call at (L3, C3) |
| 39 | + public static void OtherInterceptorMethod(this C c, int param) |
| 40 | + { |
| 41 | + Console.WriteLine($"other interceptor {param}"); |
| 42 | + } |
| 43 | +} |
| 44 | +``` |
| 45 | + |
| 46 | +## Detailed design |
| 47 | +[design]: #detailed-design |
| 48 | + |
| 49 | +### InterceptsLocationAttribute |
| 50 | + |
| 51 | +A method indicates that it is an *interceptor* by adding one or more `[InterceptsLocation]` attributes. These attributes refer to the source locations of the calls it intercepts. |
| 52 | + |
| 53 | +```cs |
| 54 | +namespace System.Runtime.CompilerServices |
| 55 | +{ |
| 56 | + [AttributeUsage(AttributeTargets.Method, AllowMultiple = true)] |
| 57 | + public sealed class InterceptsLocationAttribute(string filePath, int line, int character) : Attribute |
| 58 | + { |
| 59 | + } |
| 60 | +} |
| 61 | +``` |
| 62 | + |
| 63 | +Any "ordinary method" (i.e. with `MethodKind.Ordinary`) can have its calls intercepted. |
| 64 | + |
| 65 | +`[InterceptsLocation]` attributes included in source are emitted to the resulting assembly, just like other custom attributes. |
| 66 | + |
| 67 | +PROTOTYPE(ic): We may want to recognize `file class InterceptsLocationAttribute` as a valid declaration of the attribute, to allow generators to bring the attribute in without conflicting with other generators which may also be bringing the attribute in. See open question in [User opt-in](#user-opt-in). |
| 68 | +https://github.com/dotnet/roslyn/issues/67079 is a bug which causes file-local source declarations of well-known attributes to be generally treated as known. When that bug is fixed, we may want to single out `InterceptsLocationAttribute` as "recognized, even though they are file-local". |
| 69 | + |
| 70 | +#### File paths |
| 71 | + |
| 72 | +File paths used in `[InterceptsLocation]` are expected to have `/pathmap` substitution already applied. Generators should accomplish this by locally recreating the file path transformation performed by the compiler: |
| 73 | + |
| 74 | +```cs |
| 75 | +using Microsoft.CodeAnalysis; |
| 76 | + |
| 77 | +string GetInterceptorFilePath(SyntaxTree tree, Compilation compilation) |
| 78 | +{ |
| 79 | + return compilation.Options.SourceReferenceResolver?.NormalizePath(tree.FilePath, baseFilePath: null) ?? tree.FilePath; |
| 80 | +} |
| 81 | +``` |
| 82 | + |
| 83 | +The file path given in the attribute must be equal by ordinal comparison to the value given by the above function. |
| 84 | + |
| 85 | +The compiler does not map `#line` directives when determining if an `[InterceptsLocation]` attribute intercepts a particular call in syntax. |
| 86 | + |
| 87 | +#### Position |
| 88 | + |
| 89 | +Line and column numbers in `[InterceptsLocation]` are 1-indexed to match existing places where source locations are displayed to the user. For example, in `Diagnostic.ToString`. |
| 90 | + |
| 91 | +The location of the call is the location of the simple name syntax which denotes the interceptable method. For example, in `app.MapGet(...)`, the name syntax for `MapGet` would be considered the location of the call. For a static method call like `System.Console.WriteLine(...)`, the name syntax for `WriteLine` is the location of the call. If we allow intercepting calls to property accessors in the future (e.g `obj.Property`), we would also be able to use the name syntax in this way. |
| 92 | + |
| 93 | +#### Attribute creation |
| 94 | + |
| 95 | +The goal of the above decisions is to make it so that when source generators are filling in `[InterceptsLocation(...)]`, they simply need to read `nameSyntax.SyntaxTree.FilePath` and `nameSyntax.GetLineSpan().Span.Start` for the exact file path and position information they need to use. |
| 96 | + |
| 97 | +We should provide samples of recommended coding patterns for generator authors to show correct usage of these, including the "translation" from 0-indexed to 1-indexed positions. |
| 98 | + |
| 99 | +### Non-invocation method usages |
| 100 | + |
| 101 | +Conversion to delegate type, address-of, etc. usages of methods cannot be intercepted. |
| 102 | + |
| 103 | +Interception can only occur for calls to ordinary member methods--not constructors, delegates, properties, local functions, operators, etc. Support for more member kinds may be added in the future. |
| 104 | + |
| 105 | +### Arity |
| 106 | + |
| 107 | +Interceptors cannot have type parameters or be declared in generic types at any level of nesting. |
| 108 | + |
| 109 | +This limitation prevents interceptors from matching the signature of an interceptable call in cases where the interceptable call uses type parameters which are not in scope at the interceptor declaration. We can consider adjusting the rules to alleviate this limitation if compelling scenarios arise for it in the future. |
| 110 | + |
| 111 | +```cs |
| 112 | +using System.Runtime.CompilerServices; |
| 113 | + |
| 114 | +class C |
| 115 | +{ |
| 116 | + public static void InterceptableMethod<T1>(T1 t) => throw null!; |
| 117 | +} |
| 118 | + |
| 119 | +static class Program |
| 120 | +{ |
| 121 | + public static void M<T2>(T2 t) |
| 122 | + { |
| 123 | + C.InterceptableMethod(t); |
| 124 | + } |
| 125 | +} |
| 126 | + |
| 127 | +static class D |
| 128 | +{ |
| 129 | + [InterceptsLocation("Program.cs", 12, 11)] |
| 130 | + public static void Interceptor1(object s) => throw null!; |
| 131 | +} |
| 132 | +``` |
| 133 | + |
| 134 | +### Signature matching |
| 135 | + |
| 136 | +When a call is intercepted, the interceptor and interceptable methods must meet the signature matching requirements detailed below: |
| 137 | +- When an interceptable instance method is compared to a classic extension method, we use the extension method in reduced form for comparison. The extension method parameter with the `this` modifier is compared to the instance method `this` parameter. |
| 138 | +- The returns and parameters, including the `this` parameter, must have the same ref kinds and types. |
| 139 | +- A warning is reported instead of an error if a type difference is found where the types are not distinct to the runtime. For example, `object` and `dynamic`. |
| 140 | +- No warning or error is reported for a *safe* nullability difference, such as when the interceptable method accepts a `string` parameter, and the interceptor accepts a `string?` parameter. |
| 141 | +- Method names and parameter names are not required to match. |
| 142 | +- Parameter default values are not required to match. When intercepting, default values on the interceptor method are ignored. |
| 143 | +- `params` modifiers are not required to match. |
| 144 | +- `scoped` modifiers and `[UnscopedRef]` must be equivalent. |
| 145 | +- In general, attributes which normally affect the behavior of the call site, such as `[CallerLineNumber]` are ignored on the interceptor of an intercepted call. |
| 146 | + - The only exception to this is when the attribute affects "capabilities" of the method in a way that affects safety, such as with `[UnscopedRef]`. Such attributes are required to match across interceptable and interceptor methods. |
| 147 | + |
| 148 | +Arity does not need to match between intercepted and interceptor methods. In other words, it is permitted to intercept a generic method with a non-generic interceptor. |
| 149 | + |
| 150 | +### Conflicting interceptors |
| 151 | + |
| 152 | +If more than one interceptor refers to the same location, it is a compile-time error. |
| 153 | + |
| 154 | +If an `[InterceptsLocation]` attribute is found in the compilation which does not refer to the location of an explicit method call, it is a compile-time error. |
| 155 | + |
| 156 | +### Interceptor accessibility |
| 157 | + |
| 158 | +An interceptor must be accessible at the location where interception is occurring. |
| 159 | + |
| 160 | +An interceptor contained in a file-local type is permitted to intercept a call in another file, even though the interceptor is not normally *visible* at the call site. |
| 161 | + |
| 162 | +This allows generator authors to avoid *polluting lookup* with interceptors, helps avoid name conflicts, and prevents use of interceptors in *unintended positions* from the interceptor author's point-of-view. |
| 163 | + |
| 164 | +We may also want to consider adjusting behavior of `[EditorBrowsable]` to work in the same compilation. |
| 165 | + |
| 166 | +### Editor experience |
| 167 | + |
| 168 | +Interceptors are treated like a post-compilation step in this design. Diagnostics are given for misuse of interceptors, but some diagnostics are only given in the command-line build and not in the IDE. There is limited traceability in the editor for which calls in a compilation are actually being intercepted. If this feature is brought forward past the experimental stage, this limitation will need to be re-examined. |
| 169 | + |
| 170 | +### User opt-in |
| 171 | + |
| 172 | +Interceptors will require a feature flag during the experimental phase. The flag can be enabled with `/features=InterceptorsPreview` on the command line or `<Features>InterceptorsPreview</Features>` in msbuild. |
| 173 | + |
| 174 | +### Implementation strategy |
| 175 | + |
| 176 | +During the binding phase, `InterceptsLocationAttribute` usages are decoded and the related data for each usage are collected in a `ConcurrentSet` on the compilation: |
| 177 | +- intercepted file-path and location |
| 178 | +- attribute location |
| 179 | +- attributed method symbol |
| 180 | + |
| 181 | +At this time, diagnostics are reported for the following conditions: |
| 182 | +- problems specific to the attributed interceptor method itself, for example, that it is not an ordinary method. |
| 183 | +- syntactic problems specific to the referenced location, for example, that it does not refer to an applicable simple name as defined in [Position](#position) subsection. |
| 184 | + |
| 185 | +During the lowering phase, when a given `BoundCall` is lowered: |
| 186 | +- we check if its syntax contains an applicable simple name |
| 187 | +- if so, we lookup whether it is being intercepted, based on data about `InterceptsLocationAttribute` collected during the binding phase. |
| 188 | +- if it is being intercepted, we perform an additional step after lowering of the receiver and arguments is completed: |
| 189 | + - substitute the interceptable method with the interceptor method on the `BoundCall`. |
| 190 | + - if the interceptor is a classic extension method, and the interceptable method is an instance method, we adjust the `BoundCall` to use the receiver as the first argument of the call, "pushing" the other arguments forward, similar to the way it would have bound if the original call were to an extension method in reduced form. |
| 191 | + |
| 192 | +At this time, diagnostics are reported for the following conditions: |
| 193 | +- incompatibility between the interceptor and interceptable methods, for example, in their signatures. |
| 194 | +- *duplicate* `[InterceptsLocation]`, that is, multiple interceptors which intercept the same call. |
| 195 | +- interceptor is not accessible at the call site. |
0 commit comments