Wrong comment char for rust code

[0xpr03]

I'm not sure if I'm on the right place for this: https://michael-f-bryan.github.io/rust-ffi-guide/fun/problems.html All your examples have the following code inside:

# #![allow(unused_variables)]
#fn main() {

~~This won't ever compile as # is not a correct comment char in rust. Please correct it to // or /* or leave this part out.~~

error: expected `[`, found `#`
 --> adder.rs:2:3
  |
2 | # #![allow(unused_variables)]
  |   ^

error: aborting due to previous error(s)

I'm sorry, seems like without both JS CDN's I'm seeing some code to parse.

And the first example uses "uit" not "uint", unknown type.

[Michael-F-Bryan]

I'm not sure if I'm on the right place for this:

Yep, this is the right spot :smile:

This won't ever compile as # is not a correct comment char in rust.

Please correct it to // or /* or leave this part out.

You are right in that the # character isn't a valid comment character in Rust, but it's used by rustdoc to mark code which should be part of an example but not displayed by default. You usually use it to hide a bunch of unnecessary lines like imports so they don't clutter the example code. The Book mentions this towards the end of the "Documentation as Tests" section.

In this case it looks like mdbook automatically wraps all Rust code snippets in that automatically so you have a valid program which can be run in the playpen. I'm not sure there's much I can do from my side of things to remove the lines, short of using a patched version of mdbook...

If you look at the actual source for that page you'll see that the lines in question aren't part of the code snippet:

[0xpr03]

Updated, looks like it's done by the two JS-CDN's embedded in the site. So my default external block stopped this from parsing. If I enable these in uMatrix everything works fine again ^^

[Michael-F-Bryan]

@0xpr03, you shouldn't be seeing those lines by default... Did you hit the "expand" button by any chance?

This is what I see without hitting the expand button:

And after:

If you are seeing the latter screenshot when you first visit the page then that's a bug in whatever JS mdbook uses.

[0xpr03]

No, the problem is that without code.jquery & cdn.jsdelivery the site looks as attached.

I didn't even consider the # to be part of the code formating JS. So this was kinda my fault.

[Michael-F-Bryan]

That's interesting. I never would have thought to see what happens when you block javascript and other background requests. I guess mdbook should degrade gracefully, but I'm not exactly sure how they'd accomplish that.

I got curious about what uMatrix does so I had a quick skim through the README on their GitHub repo. Apparently it's not uncommon for it to break things.

Regarding broken sites

uMatrix does not guarantee that sites will work fine: it is for advanced users who can figure how to un-break sites, because essentially uMatrix is a firewall which works in relaxed block-all/allow-exceptionally mode out of the box: it is not unexpected that sites will break.

So this means do not file issues to report broken sites when the sites are broken because uMatrix does its job as expected. I will close any such issue without further comment.

[0xpr03]

Apparently it's not uncommon for it to break things.

That's true, as I'm using it since some time ago together with it's better known browther uBlock Origin I've gotten around to see some really horrifying site constructions, displaying a blank page without 4+ external JS provider ;) Anyway, I just didn't expect the raw site to contain stuff that's obviously not even required ( like the main() ) which will in turn be removed by the JS code. I looked like you've had some old code around there which was commented out.