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

Fix Erlang Scanning & Warnings #1818

Merged

Conversation

garazdawi
Copy link
Contributor

This PR does 3 things:

  1. Change Erlang Elixir autolinking to parse function links using specialized code instead of sharing. There are too many incompatible overlaps between the languages to make it possible to use the same parser for both.
  2. Use correct line numbers for regular links, just as More accurate autolink warnings line #1807 did for Elixir
  3. Make Erlang docs warn when an unkown type or callback is used in regular links.

I'm a bit unsure about the last one, why is it that ExDoc Elixir does not warn for these?

`t:Bad:type/0`

Seems like there is very little chance of a false positive, and if there is one you can always silence it.

This makes it so that we do not have to deal with parsing
Erlang using the Elixir parser, things that are keywords in Elixir
are not in Erlang and vice versa.

The most recent example I came across was `c:do/1` which is valid
in Erlang but not in Elixir.
@josevalim
Copy link
Member

Elixir should warn for types I think. @wojtekmach, maybe it is worth implementing that when you implement m:. All of m:, t:, and c: should warn if not found.

@@ -432,7 413,7 @@ defmodule ExDoc.Autolink do
{:type, _visibility} ->
case config.language.try_builtin_type(name, arity, mode, config, original_text) do
nil ->
if mode == :custom_link do
if mode == :custom_link or config.language == ExDoc.Language.Erlang do
Copy link
Member

Choose a reason for hiding this comment

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

Is this check here to avoid warning in Elixir? If so, you can go ahead and warn. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes it is, but if I remove it a lot (~20) of tests break (or not break, but they start to emit warnings to stdout).

Copy link
Member

Choose a reason for hiding this comment

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

Ok, @wojtekmach please look into it afterwards then. :)

Ideally we want to avoid hardcoding the language here, an option would be better, but since this is temporary, it is fine by me. :)

{:regular_link, _module_visibility, :undefined} when not same_module? ->
{:regular_link, _module_visibility, :undefined}
when not same_module? and
(config.language != ExDoc.Language.Erlang or kind == :function) ->
Copy link
Member

Choose a reason for hiding this comment

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

Same here, feel free to let it warn on Elixir, assuming it is one of m:, t: or c:.

@garazdawi
Copy link
Contributor Author

I found a bug in how warnings are reported from extra files, please don't merge until I've fixed it.

@garazdawi garazdawi force-pushed the lukas/fix-erlang-warnings-and-scanning branch from 5d20aec to 774aacd Compare November 15, 2023 14:28
@garazdawi
Copy link
Contributor Author

Turns out that it was an issue in :elixir_errors that has already been fixed.

Feel free to merge whenever you feel like.

@garazdawi garazdawi force-pushed the lukas/fix-erlang-warnings-and-scanning branch from 71b36b8 to db1c726 Compare November 15, 2023 14:51
@wojtekmach wojtekmach merged commit 4f5a221 into elixir-lang:main Nov 15, 2023
4 checks passed
@wojtekmach
Copy link
Member

Thank you!

Same here, feel free to let it warn on Elixir, assuming it is one of m:, t: or c:.

Good call, will do!

@wojtekmach
Copy link
Member

wojtekmach commented Nov 21, 2023

@garazdawi I think after this PR your OTP branch with ExDoc markdown is now crashing and I was able to narrow it down to ExDoc emitted warnings for docs defined in .hrl files. ExDoc gets the file as .erl and tries to render a line in it that doesn't exist, it should look into .hrl file. Unfortunately I couldn't reproduce this in a test yet. Our markdown doc tests are going through the legacy edoc machinery in test_helper and I think ideally we'd have another code path where we extract things from -doc. I'd appreciate any advice how to go about that!

@garazdawi
Copy link
Contributor Author

Yes, I'm aware. I've fixed it in a local branch together with some other fixes. The problem happens when we have doc entries with different file anno than the moduledoc and then when ExDoc tries to warn it takes the snippet from the wrong file.

The branch with my current fixes is: https://github.com/garazdawi/ex_doc/commits/lukas/fix-erlang-doc-support/

and the fix for this particular issue is: garazdawi@0cfc40b

@josevalim
Copy link
Member

FWIW EEP 48 expects the Anno node to point to the source and it has an optional metadata that points to the edit_url. I am not sure we use them both in ExDoc but we will be glad to accommodate!

@garazdawi
Copy link
Contributor Author

FWIW EEP 48 expects the Anno node to point to the source and it has an optional metadata that points to the edit_url. I am not sure we use them both in ExDoc but we will be glad to accommodate!

From what I've gathered, for ExDoc to work, Anno should point to the first line of the documentation. This is used when printing warnings by ExDoc etc. For application/html erlang, the Anno points to the source code (or should anyway, seems like there are bugs there).

Then ExDoc outputs a "view source" button that points to the source code, this is currently taken from the anno in the AST. (This only works for types in Erlang right now, yet another thing to fix :) )

Maybe it would make sense to have an "edit documentation" button that takes you to a page where you can update the docs?

@wojtekmach
Copy link
Member

@garazdawi I created an issue to discuss Edit Documentation link: #1825.

@wojtekmach
Copy link
Member

@garazdawi I cherry-picked all commits except using makeup_erlang fork (as we can't release to Hex with that) from https://github.com/garazdawi/ex_doc/commits/lukas/fix-erlang-doc-support/ on main.

If you could send a PR to makeup_erlang we can release it too. If there's any other ExDoc things you'd like to land before the release, let us know too!

@garazdawi
Copy link
Contributor Author

Great! I've meant to open a PR for weeks now, but other things have always gotten in the way. I will send a pr to makeup_erlang.

I don't have anything right now lined up for ExDoc, but I don't doubt that as we start converting more and more of our docs and other people start to look at it there will be issues and inconsistencies that come up.

@josevalim
Copy link
Member

makeup_erlang v0.1.3 also released!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants