Skip to content

Fixed broken xref in Utf8JSonWriter #2422

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.

Sign up for GitHub

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

Merged
rpetrusha merged 1 commit into from
May 23, 2019
Merged

Fixed broken xref in Utf8JSonWriter #2422

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion xml/System.Text.Json/Utf8JsonWriter.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,8 +31,10 @@
`Utf8JsonWriter` writes the text sequentially with no caching and by default adheres to the [JSON RFC](https://tools.ietf.org/html/rfc8259), with the exception of writing comments.

A method that attempts to write invalid JSON when validation is enabled throws a <xref:System.InvalidOperationException> with a context-specific error message.

Since this type is a ref struct, it does not directly support async. However, it does provide support for reentrancy to write partial data and to continue writing in chunks.
To be able to format the output with indentation and white space OR to skip validation, create an instance of <xref:System.Text.Json.JsonWriterState> and pass that in to the writer.

To be able to format the output with indentation and white space OR to skip validation, create an instance of <xref:System.Text.Json.JsonWriterOptions> and pass it in to the writer.

@ahsonkhan ahsonkhan May 10, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This isn't the only change that would need to be made. The type is no longer a ref struct, and a few APIs/comments changed.

@ahsonkhan ahsonkhan May 10, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We should probably re-run the tool to grab comments from source similar to what @carlossanlop had done previously (#2360)

@carlossanlop carlossanlop May 20, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Hey team, I re-ran the tool and opened a new PR with the most up to date API versions: #2471

@mairaw mairaw May 21, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That PR doesn't contain this change so do we need to run the tool replacing existing content too?

@ahsonkhan ahsonkhan May 22, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this is the case of "merge-conflict (case 2 below)" which means we need to manually update the contents to match the new content.

Here are the cases:

  1. Source contains comments, docs repo doesn't - @carlossanlop tool captures the diff and adds the content.
  2. Source contains comments, docs contains comments - usually do nothing (the tool ignores this), docs are the source of truth (unless an update was required/API change/etc - then manual updates needed).
  3. Source doesn't contain comments, docs repo contains comments - do nothing, we have the docs already.
  4. Source doesn't contain comments, docs repo doesn't contain comments - dev/docs team should add comments to this repo.


]]></format>
</remarks>
Expand Down