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

Move #if NET directives forward #75500

Merged
merged 2 commits into from
Oct 17, 2024
Merged

Move #if NET directives forward #75500

merged 2 commits into from
Oct 17, 2024

Conversation

jjonescz
Copy link
Member

Part of #75453.

cc @jaredpar

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Oct 14, 2024
@jjonescz jjonescz marked this pull request as ready for review October 14, 2024 13:48
@jjonescz jjonescz requested review from a team as code owners October 14, 2024 13:48
@@ -117,7 +117,7 @@ public static bool TryHash(ReadOnlySpan<byte> source, Span<byte> destination, ou
return false;
}

#if NET7_0_OR_GREATER
#if NET8_0_OR_GREATER
Copy link
Member

Choose a reason for hiding this comment

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

i don't understaand this change. it wraps using Uint128. Which was added in .net 7.

Copy link
Member Author

Choose a reason for hiding this comment

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

From #75453 (comment):

When people see #if NET7 in code but no net7.0 in the TFM list then there is a tendency to ask "wait, is that stale? can we remove that?" Hence I like to roll them forward to make sure that we still need them and to make it clearer to readers that they are intended.

Copy link
Member

Choose a reason for hiding this comment

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

Correct. Essentially we do not target net7.0 anymore hence leaving #if NET7_... directives around opens questions when reading the code. At a glance it's unclear if that is a directive that we still need or one that was accidentally left after other changes.

When doing this changes in the past I've found all manner of unused / legacy directives in the code (many I added to be fair). Found that if we keep pushing it forward like this it makes it easier to see that it's tied to our modern build semantics

Copy link
Member

Choose a reason for hiding this comment

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

so in this case, we want to move to NET8 pragma, even though it's really that it was NET7 that added this api? if that's the design, then that's fine with me. I just wanted to confirm that was how we think it's best to do things.

@@ -342,7 +342,7 @@ public static void CopyAccumulators(ref State state, ulong* accumulators)
{
fixed (ulong* stateAccumulators = state.Accumulators)
{
#if NET7_0_OR_GREATER
#if NET8_0_OR_GREATER
Copy link
Member

Choose a reason for hiding this comment

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

same with these checks. the apis we're gating around are on .net7. this would mean we would fall back to the lower performance code there.

Copy link
Member Author

Choose a reason for hiding this comment

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

the apis we're gating around are on .net7. this would mean we would fall back to the lower performance code there.

We no longer target net7.

@@ -19,7 +19,7 @@ internal static class TextReaderExtensions
// If we're on .NET Core 7.0 the implementation is easy, but on older versions we don't have the helper and since we also don't have
// Microsoft.VisualStudio.Threading's WithCancellation helper we have to inline the same approach.

#if NET7_0_OR_GREATER
Copy link
Member

Choose a reason for hiding this comment

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

Comment also needs updating.

Copy link
Member

Choose a reason for hiding this comment

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

Although it's not clear to me why this isn't just #if NET now...

Copy link
Member Author

Choose a reason for hiding this comment

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

Although it's not clear to me why this isn't just #if NET now...

Sounds like a pre-existing issue. This PR should be just mechanical update - when we update our TFM, we move these #ifs forward.

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

Successfully merging this pull request may close these issues.

7 participants