Skip to content

Conversation

@paulo-ferraz-oliveira
Copy link
Collaborator

@paulo-ferraz-oliveira paulo-ferraz-oliveira commented Jun 10, 2025

I add the minimum requirements to have elvis_core not throw (and parse) for upcoming rule change operator_spaces (around <:= and <:-, for lists, binaries and maps)

We could think about moving minimum_otp_vsn to 26, now that 28 is out.

I changed the scope of the PR (was what is now struck through; now is what the title states) following discussions around preferences. I'll move it to draft until I have time to work on more changes.

Fix #89.

The process

For future reference:

  1. I copied a formatted version of epp_dodger over a formatted version of ktn_dodger and adjusted the latter accordingly (take care to not ruin the "format" in place - eases review?).
  2. I made sure rebar3 test was ✅
  3. I added some tests for newer syntax
  4. I checked changes to absform.md (https://github.com/erlang/otp/blob/master/erts/doc/guides/absform.md) and the mentioned modules:
  • epp
  • erl_eval
  • erl_lint
  • erl_parse
  • erl_pp
  • absform.md ℹ️ this was possibly the most useful of the bunch
  1. I checked changes to:
  • erl_syntax
  • erl_prettypr
  1. I ran a test, mentioned below, on the whole of OTP's codebase to find exceptions

Interesting commits:

@paulo-ferraz-oliveira paulo-ferraz-oliveira changed the title Allow parsing generate_strict and b_generate_strict Allow parsing generate_strict, b_generate_strict, m_generate_strict Jun 10, 2025
@paulo-ferraz-oliveira paulo-ferraz-oliveira changed the title Allow parsing generate_strict, b_generate_strict, m_generate_strict Allow parsing generate_strict, b_generate_strict, m_generate_strict, zip Jun 10, 2025
@paulo-ferraz-oliveira paulo-ferraz-oliveira marked this pull request as ready for review June 10, 2025 23:42
@paulo-ferraz-oliveira
Copy link
Collaborator Author

I don't have permissions to change

image

but feel free to do it, if you like the change.

@paulo-ferraz-oliveira paulo-ferraz-oliveira force-pushed the fix/for-strict-generators branch from 39133b3 to 48fdf42 Compare June 11, 2025 00:12
Copy link
Member

@elbrujohalcon elbrujohalcon left a comment

Choose a reason for hiding this comment

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

My goal with #89 was to make these changes but also compare OTP28's epp_dodger against OTP27's epp_dodger and adjust ktn_dodger accordingly… like we usually do with every OTP version update.
Then, based on that, adjust ktn_code, the tests, and everything else here.
I believe we can wait a little bit more and do the whole move to OTP28 properly instead of introducing just what we need for Elvis to handle OTP28 files.

@elbrujohalcon elbrujohalcon mentioned this pull request Jun 11, 2025
@paulo-ferraz-oliveira
Copy link
Collaborator Author

My goal with #89 was to make these changes but also compare OTP28's epp_dodger against OTP27's epp_dodger and adjust ktn_dodger accordingly… like we usually do with every OTP version update. Then, based on that, adjust ktn_code, the tests, and everything else here. I believe we can wait a little bit more and do the whole move to OTP28 properly instead of introducing just what we need for Elvis to handle OTP28 files.

Sure, or we can incrementally improve this via the open issue. I'm not sure how big the PR will end up being, but I must say I prefer smaller scope changes. The same reasoning applies to the Elvis Core change: better to do it incrementally. In any case, I'll separate the other one in two so it's easier to reason on.

@elbrujohalcon
Copy link
Member

My perspective is that I prefer a single PR, with all the changes, to be sure we don't miss anything.

@paulo-ferraz-oliveira
Copy link
Collaborator Author

My perspective is that I prefer a single PR, with all the changes, to be sure we don't miss anything.

I won't argue with this preference, as long as when the final PR comes you don't ask me to split it up 😆

@paulo-ferraz-oliveira paulo-ferraz-oliveira changed the title Allow parsing generate_strict, b_generate_strict, m_generate_strict, zip Support OTP 28 Jun 11, 2025
@paulo-ferraz-oliveira paulo-ferraz-oliveira marked this pull request as draft June 11, 2025 15:46
@paulo-ferraz-oliveira
Copy link
Collaborator Author

@elbrujohalcon, shall we up the minimum to OTP 26 when this pull request is ready for review?

@paulo-ferraz-oliveira paulo-ferraz-oliveira added this to the 2.4.0 milestone Jun 11, 2025
@paulo-ferraz-oliveira
Copy link
Collaborator Author

I tentatively assigned this to 2.4.0.

@elbrujohalcon
Copy link
Member

My perspective is that I prefer a single PR, with all the changes, to be sure we don't miss anything.

I won't argue with this preference, as long as when the final PR comes you don't ask me to split it up 😆

Pinky promise.

@elbrujohalcon
Copy link
Member

@elbrujohalcon, shall we up the minimum to OTP 26 when this pull request is ready for review?

YES!

@paulo-ferraz-oliveira
Copy link
Collaborator Author

paulo-ferraz-oliveira commented Jun 11, 2025

@elbrujohalcon, I think I was pretty thorough in the code comparisons (and we seem to cover absform.md 100%)... I'm gonna write a local test to analyse all the .erl from the Erlang codebase and see if something surfaces.

Done: test code was

parse_erl_for(Dir) ->
    case file:list_dir(Dir) of
        {ok, Entries} ->
            lists:foreach(
                fun(Entry) ->
                    FullPath = filename:join(Dir, Entry),
                    case filelib:is_dir(FullPath) of
                        true ->
                            parse_erl_for(FullPath);
                        false ->
                            filename:extension(Entry) =:= ".erl" andalso
                                try
                                    {ok, Binary} = file:read_file(FullPath),
                                    ktn_code:parse_tree(Binary)
                                catch
                                    Class:Reason:S ->
                                        erlang:display({exc, Class, Reason, FullPath, S})
                                end
                    end
                end,
                Entries
            );
        {error, _Reason} ->
            error
    end.

3801 analysed, and the output is

expected {error,function_clause,"<path_to_otp>/lib/xmerl/doc/examples/sdocbook2xhtml.erl"}
handled  {throw,{unhandled_abstract_form,{error,{{6,2},ktn_dodger,{warning,"-warning ( \"a warning\" )."}}}},"<path_to_otp>/lib/tools/test/make_SUITE_data/test1.erl"}
expected {error,{badmatch,{error,{{38,12},erl_scan,{illegal,string}},{38,12}}},"<path_to_otp>/lib/wx/api_gen/wx_extra/wxTaskBarIcon.erl"}
expected {error,{badmatch,{error,{{72,12},erl_scan,{illegal,string}},{72,12}}},"<path_to_otp>/lib/wx/api_gen/wx_extra/wxPrintout.erl"}
expected {error,{badmatch,{error,{{32,12},erl_scan,{illegal,string}},{32,12}}},"<path_to_otp>/lib/wx/api_gen/wx_extra/wxListCtrl.erl"}
expected {error,function_clause,"<path_to_otp>/lib/edoc/test/edoc_SUITE_data/un1.erl"}
expected {error,function_clause,"<path_to_otp>/lib/edoc/test/edoc_SUITE_data/un3.erl"}
expected {error,function_clause,"<path_to_otp>/lib/ssh/examples/ssh_sample_cli.erl"}
handled  {throw,{unhandled_abstract_form,{error,{{32,2},ktn_dodger,{warning,"-warning ( \"Ignore me -- testing that the debugger can handle warnings\" )."}}}},"<path_to_otp>/lib/common_test/test/ct_auto_compile_SUITE.erl"}
handled  {throw,{unhandled_abstract_form,{error,{{34,2},ktn_dodger,{warning,"-warning ( \"Ignore me -- testing that the debugger can handle warnings\" )."}}}},"<path_to_otp>/lib/debugger/test/andor_SUITE.erl"}
expected {error,function_clause,"<path_to_otp>/lib/compiler/test/compile_SUITE_data/bad_enc.erl"}

I'm gonna check if any of this is fixable, but these seem like corner cases, basically.

Yeah, so this results in a further commit for a fix, but all the other cases are basically the UTF-8 -related oddities being tested.

@paulo-ferraz-oliveira paulo-ferraz-oliveira marked this pull request as ready for review June 12, 2025 00:35
Copy link
Member

@elbrujohalcon elbrujohalcon left a comment

Choose a reason for hiding this comment

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

I know it sucks and I'm truly sorry to request this but… I would like changes to ktn_dodger to be just the new additions (i.e., no formatting, no function renaming, no atom enclosing, etc…).
The docs as comments is clever. I didn't do it last time because it didn't occur to me that I could just put the new -doc attributes in comments. Those ones should stay :)

@paulo-ferraz-oliveira
Copy link
Collaborator Author

paulo-ferraz-oliveira commented Jun 12, 2025

I would like changes to ktn_dodger to be just the new additions (i.e., no formatting, no function renaming, no atom enclosing, etc…).

How so? If you do the procedure above it's much simpler to find the differences by copy-pasting over the file. And then we don't have to deal with all the function name changes, etc. What's your rationale, though?

No a big issue; I'll spend some time moving this back, but the list of changes will probably be smaller, in the end.

@paulo-ferraz-oliveira paulo-ferraz-oliveira force-pushed the fix/for-strict-generators branch from 272478a to 18d80c7 Compare June 12, 2025 22:31
@paulo-ferraz-oliveira
Copy link
Collaborator Author

erlfmt, even if asked to not format something, decided to remove 2 consecutive blank lines. Hope that's Ok.

@paulo-ferraz-oliveira
Copy link
Collaborator Author

Feel free to merge and release; I think I addressed all your comments. I'll then import the new version next to elvis_core.

@elbrujohalcon elbrujohalcon merged commit 6b56f8e into inaka:main Jun 13, 2025
3 checks passed
@paulo-ferraz-oliveira paulo-ferraz-oliveira deleted the fix/for-strict-generators branch June 13, 2025 19:58
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.

Support OTP 28

2 participants