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

[SYCL][DOC] Move deprecated extensions #5458

Merged
merged 4 commits into from
Feb 2, 2022

Conversation

gmlueck
Copy link
Contributor

@gmlueck gmlueck commented Feb 1, 2022

Move these deprecated extension specifications to the "deprecated"
directory, but add a signpost file in the "supported" directory pointing
at the deprecated extension.

We will follow this convention when a supported extension is deprecated.
The deprecated extension will move to the "deprecated" directory, and
we will change the file in the "supported" directory into a signpost. Thus,
any external links to the spec will still point to something that leads to the
deprecated extension.

Move these deprecated extension specifications to the "supported"
directory.  We decided to keep the deprecated extensions in this
directory because:

* Deprecated extensions are still supported.
* We want to avoid breaking hyperlinks to an extension when
  transitioning from supported to deprecated.
@gmlueck gmlueck requested a review from a team February 1, 2022 22:11
@gmlueck gmlueck requested a review from a team as a code owner February 1, 2022 22:11
Pennycook
Pennycook previously approved these changes Feb 1, 2022
@pvchupin
Copy link
Contributor

pvchupin commented Feb 1, 2022

Is there any way to distinguish supported from supported-but-deprecated?

bader
bader previously approved these changes Feb 2, 2022
@gmlueck
Copy link
Contributor Author

gmlueck commented Feb 2, 2022

Is there any way to distinguish supported from supported-but-deprecated?

At present you need to open the file and read the content. A deprecated extension will contain a note near the top saying it is deprecated. All three of the deprecated extensions in this PR have such a note, though I admit that we should find some better formatting to make this stand out better.

We originally planned to have a "deprecated" directory, and we would move the specification there when it becomes deprecated. However, @romanovvlad noted that this would cause anyone with an eternal link to the spec to have a broken link.

I see three options:

  1. Keep the current POR organization where supported and deprecated extensions are both in the "supported" directory. People will need to read the file to see whether an extension is deprecated.

  2. Go back to our original plan where there is a "deprecated" directory. If people get a broken link, they will need to learn to look for the extension in the "deprecated" directory. The directory structure is pretty obvious, so many people will probably figure this out.

  3. Create a "deprecated" folder but also keep a "signpost" file in the "supported" folder. The signpost file will just have some text the says something like:

    This extension is deprecated. See "../deprecated/".

    This is not very much different from option (1) because you still need to open the file to tell whether it is deprecated.

Note that option (2) is the only one that lets you quickly get a list of all the non-deprecated supported extensions (you just look at the list of files in the "supported" directory). So, if this is important, we should choose that option.

@pvchupin
Copy link
Contributor

pvchupin commented Feb 2, 2022

option (3) looks like the best one.

Move the specs instead to the "deprecated" folder and add a signpost
file to the "supported" folder.
@gmlueck gmlueck dismissed stale reviews from bader and Pennycook via ad0d48b February 2, 2022 18:39
@gmlueck
Copy link
Contributor Author

gmlueck commented Feb 2, 2022

option (3) looks like the best one.

Works for me. Done in ad0d48b

@gmlueck gmlueck requested review from Pennycook and bader February 2, 2022 18:46
@bader bader requested a review from pvchupin February 2, 2022 18:48
Update the links to go to the extension in the "deprecated" directory
instead of to the signpost file.
pvchupin
pvchupin previously approved these changes Feb 2, 2022
Pennycook
Pennycook previously approved these changes Feb 2, 2022
@bader bader dismissed stale reviews from Pennycook and pvchupin via cffc4af February 2, 2022 19:52
@bader bader merged commit 09be931 into intel:sycl Feb 2, 2022
@gmlueck gmlueck deleted the gmlueck/mv-deprecated branch February 2, 2022 20:03
alexbatashev added a commit to alexbatashev/llvm that referenced this pull request Feb 5, 2022
* upstream/sycl: (3571 commits)
  [ESIMD] Doxygen update part III - core APIs. (intel#5472)
  [SYCL][DOC] Move proposed FPGA extensions (intel#5453)
  [SYCL] Add -fsycl-fp32-prec-sqrt flag (intel#5309)
  [SYCL] Emit program build logs for warning levels >= 2 (intel#5319)
  [SYCL] Add clang support for code_location in KernelInfo (intel#5335)
  [SYCL][Doc] Move FPGA extensions (intel#5470)
  [ESIMD] Fix public simd and simd_view APIs. (intel#5465)
  [SYCL] Deprecate sycl::atomics in SYCL 2020 mode (intel#5440)
  [SYCL] Add unit test for PR 5414 (intel#5450)
  [XPTI] Allow arbitrary data types in metadata (intel#4998)
  [SYCL][DOC] Move discard queue events to supported (intel#5452)
  [Driver][SYCL] Initial support for allowing fat static -lname processing (intel#5413)
  [SYCL] Fix dead pointer usage if leaf buffer overflows (intel#5417)
  [SYCL][L0] Fix memory leak in USM prefetch (intel#5461)
  [SYCL][Doc] Add new free function queries proposal (intel#5106)
  [SYCL][ESIMD] Update vc-intrinsics deps to the top of the trunk (intel#5460)
  [SYCL][DOC] Move old spec constant extension spec (intel#5456)
  [SYCL][DOC] Move deprecated extensions (intel#5458)
  [SYCL][DOC] Fix links to old SubGroupMask doc (intel#5459)
  [ESIMD] Doxygen update part II - memory APIs. (intel#5443)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants