You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In .NET 5, we added some support for automatically making some loops atomic. For example, given the expression a+b+c+, we'll convert that into the equivalent of (?>a+)(?>b+)(?>c+): the c+ is at the end of the expression so nothing can backtrack into it, the b+ is always followed by a c and there's nothing b+ can give back that would match c, and similarly the a+ is always followed by a b and there's nothing a+ can give back that would match b. However, tweaking the expression slightly to a*b*c*, we'll convert that into the equivalent of a*b*(?>c*): while we still treat the c* as atomic, when analyzing the a* and b* loops and comparing them against what's guaranteed to come next, we see that the subsequent loop has a 0-lower-bound and give up, even though with a bit more analysis we could see that it's still valid to make all of these atomic. The more we can make atomic, the better, not just for performance but also for readability of code in the source generator.
The text was updated successfully, but these errors were encountered:
Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions
See info in area-owners.md if you want to be subscribed.
Issue Details
In .NET 5, we added some support for automatically making some loops atomic. For example, given the expression a+b+c+, we'll convert that into the equivalent of (?>a+)(?>b+)(?>c+): the c+is at the end of the expression so nothing can backtrack into it, theb+is always followed by acand there's nothingb+can give back that would matchc, and similarly the a+is always followed by aband there's nothinga+can give back that would matchb. However, tweaking the expression slightly to abc*, we'll convert that into the equivalent of ab(?>c*): while we still treat the c*as atomic, when analyzing thea*andb*` loops and comparing them against what's guaranteed to come next, we see that the subsequent loop has a 0-lower-bound and give up, even though with a bit more analysis we could see that it's still valid to make all of these atomic. The more we can make atomic, the better, not just for performance but also for readability of code in the source generator.
In .NET 5, we added some support for automatically making some loops atomic. For example, given the expression
a+b+c+
, we'll convert that into the equivalent of(?>a+)(?>b+)(?>c+)
: thec+
is at the end of the expression so nothing can backtrack into it, theb+
is always followed by ac
and there's nothingb+
can give back that would matchc
, and similarly thea+
is always followed by ab
and there's nothinga+
can give back that would matchb
. However, tweaking the expression slightly toa*b*c*
, we'll convert that into the equivalent ofa*b*(?>c*)
: while we still treat thec*
as atomic, when analyzing thea*
andb*
loops and comparing them against what's guaranteed to come next, we see that the subsequent loop has a 0-lower-bound and give up, even though with a bit more analysis we could see that it's still valid to make all of these atomic. The more we can make atomic, the better, not just for performance but also for readability of code in the source generator.The text was updated successfully, but these errors were encountered: