Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass caller argument expression through RoslynDebug.Assert #76435

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jjonescz
Copy link
Member

@jjonescz jjonescz commented Dec 14, 2024

Makes RoslynDebug.Assert more consistent with Debug.Assert. Without this, on .NET 9, the message "condition" is effectively being passed into Debug.Assert which is not very useful.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Dec 14, 2024
@@ -13,12 +13,21 @@ namespace Roslyn.Utilities
internal static class RoslynDebug
{
/// <inheritdoc cref="Debug.Assert(bool)"/>
#if NET9_0_OR_GREATER
[OverloadResolutionPriority(-1)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that really needed? Can't the other overload exist alone?
On .NET, they had to do this for backcompat. But as RoslynDebug is internal, I think it should be safe to just have the right overload?

Copy link
Member Author

@jjonescz jjonescz Dec 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might not be needed as you say. But I'd rather not risk some other DLL depending on this (via InternalsVisibleTo) and then getting MissingMethodExceptions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way our IVT is setup (no IVT outside our repo) it should be safe to remove this if the repo still compiles.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I will remove the overload resolution priority attribute.

@jjonescz jjonescz marked this pull request as ready for review December 23, 2024 07:57
@jjonescz jjonescz requested a review from a team as a code owner December 23, 2024 07:57
public static void Assert([DoesNotReturnIf(false)] bool condition, string message)
public static void Assert([DoesNotReturnIf(false)] bool condition,
#if NET
[CallerArgumentExpression(nameof(condition))] string? message = null
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we using the #if NET condition here? I get that only the core version of Debug.Assert has this overload but not sure if that should stop us from making RoslynDebug.Assert better.

Copy link
Member Author

@jjonescz jjonescz Dec 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CallerArgumentExpressionAttribute isn't available on net framework

public static void Assert([DoesNotReturnIf(false)] bool condition, string message)
public static void Assert([DoesNotReturnIf(false)] bool condition,
#if NET
[CallerArgumentExpression(nameof(condition))] string? message = null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[CallerArgumentExpression(nameof(condition))]

It is not clear to me how this is going to affect any existing usages of RoslynDebug.Assert, given that the parameter was not optional and, therefore, all call sites supply its value explicitly.

@@ -18,7 +18,13 @@ internal static class RoslynDebug

/// <inheritdoc cref="Debug.Assert(bool, string)"/>
[Conditional("DEBUG")]
public static void Assert([DoesNotReturnIf(false)] bool condition, string message)
public static void Assert([DoesNotReturnIf(false)] bool condition,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assert

Do we really need to maintain a private version of Assert? I was under impression that standard Debug.Assert has been appropriately decorated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with this. I thought the main reason we still kept RoslynDebug.Assert around was that we haven't removed all of the callsites.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants