fix: do not fail on empty # and #top fragments

[MichaIng]

The empty "#" and "#top" fragments are always valid without related HTML element. Browser will scroll to the top of the page. Hence lychee must not fail on those.

Fixed #1599

[MichaIng]

Went with the two == first, but lint suggests is_empty(). The two test runs show the currently inconsistent results:

1. https://github.com/lycheeverse/lychee/actions/runs/12665712696/job/35295837656
   #top in file.html succeeds, # in file.html and # + #top in file1.md fail.
2. https://github.com/lycheeverse/lychee/actions/runs/12665772582/job/35296001037
   # in file.html succeeds, #top in file.html and # + #top in file1.md fail.

On my local tests, randomly, at least one, up to all of those failed. Would be interesting to know where this inconsistency is coming from, as I would suggest the same fragment to succeed or fail every time the same way 🤔.

[thiru-appitap]

updated my findings, the resolution and test information in here

please let me know if this works.

[MichaIng]

Awesome, the embarrassingly missed empty/top fragment handling in case of existing cache entry was the solution 👍. The redundant map_or is unrelated to this PR.

[MichaIng]

Probably Rust optimises such automatically, but in code logic, it does not make sense to check first whether the fragment is contained, if it is empty or top. So instead of creating contains_fragment, it could be better in terms of performance/logic to align it with below, to skip contains_fragment = and instead do:

Suggested change

	Ok(is_emtpty_or_top_fragment || contains_fragment)
	Ok(is_emtpty_or_top_fragment
	|| file_frags.contains(fragment)
	|| file_frags.contains(&fragment_decoded as &str))

[MichaIng]

Ah no, that does not work since file_frags is moved by insert. Another approach, insert it if missing, and check the cache entry in any case afterwards. But I am not sure how to implement this correctly, with this Entry:: structure, which expects a result in both cases.

Wait a second, I have a much better idea!

[MichaIng]

Now it is checked and returned much earlier, if the fragment is empty or "top". No point to further process the URL and Markdown file, create or check the cache entry etc. Those cases can be handled just the same way as if there was no fragment at all.

[thiru-appitap]

@MichaIng
yes, indeed - this is a much better option (I'll start to to look from these perspectives too - thank you!)

one quick observation - by exiting earlier, we're postponing the extraction operation (to later) and thereby the cache updates - I don't see it creating any issues but wanted to note it here.

[MichaIng]

Yeah I was also thinking about the skipped/delayed cache entry, but it actually makes sense:

• Either the same URL is not checked with any other fragment later, then the cache entry is now skipped. It would have remained unused anyway.
• Or the same URL is checked with another fragment later, then the cache entry is created at this later point, which does not cause any downside. And the cache is not filled by an empty top "top" fragment anymore, which theoretically speeds up lookups for a nanosecond? 😄