Fix documentation for base64 #9386
Conversation
| * printfln!("%s", result_str); | ||
| * let res = hello_str.from_base64(); | ||
| * match res { | ||
| * Err(e) => println("could not decode base64: " + e); |
There was a problem hiding this comment.
I don't think that this will compile either because of the ; at the end
|
I also changed to from_utf8_opt, to prevent the condition from being raised, just to make the code more precise. I'm just beginning to learn Rust, and explicit examples are useful. |
|
I think he was referring to println! (the macro). |
|
Yeah sadly it seems now that the example shows off less functionality :(. Also, @adridu59 is correct in that I was just wondering about moving from |
|
Oh, I was not aware of that macro. Where is it defined? I think I'll replace the pattern matching by is_ok and is_none, that would make it easier to read. |
|
@Geal it's defined in |
|
@Geal: mind rebasing this to use Rather than the tildes? Our doc syntax is changing, there's a PR to change it. |
|
Needs a rebase against master. Also, would you mind squashing into just one commit? Thanks! |
|
Here it is, rebased and squashed. |
| * println!("{:?}", bytes); | ||
| * let result_str = str::from_utf8(bytes); | ||
| * println!("{}", result_str); | ||
| * let hello_str = "Hello, World".to_base64(STANDARD); |
There was a problem hiding this comment.
It looks like this still doesn't compile, to_base64 is only defined for &[u8], not &str. Perhaps this should use the bytes! macro to create an example?
|
hum, disregard that last patch, it uses into_bytes, I'll send another using the bytes! macro |
|
that one should be ok. BTW, how can I grep for a macro like bytes? I tried using macro_rules, but did not find it. |
|
It's actually a built-in syntax extension inside of |
|
Ok. Is there a part of the documentation adressing those types of macro?
|
|
There will be soon hopefully! We've recently started allowing attributes on macros, and the next step is to make a snapshot and then make "dummy versions" of all these macros inside libstd so they can all get documented. After that we need to surface them in rustdoc as well. Basically, not yet, but soon! |
Standard is now uppercase in the base64 module, and from_base64 now returns a Result
…ow, r=Jarcho Further enhance `needless_borrow`, mildly refactor `redundant_clone` This PR does the following: * Moves some code from `redundant_clone` into a new `clippy_utils` module called `mir`, and wraps that code in a function called `dropped_without_further_use`. * Relaxes the "is copyable" condition condition from rust-lang#9136 by also suggesting to remove borrows from values dropped without further use. The changes involve the just mentioned function. * Separates `redundant_clone` into modules. Strictly speaking, the last bullet is independent of the others. `redundant_clone` is somewhat hairy, IMO. Separating it into modules makes it slightly less so, by helping to delineate what depends upon what. I've tried to break everything up into digestible commits. r? `@Jarcho` (`@Jarcho` I hope you don't mind.) changelog: continuation of rust-lang#9136
Fix bug introduced by rust-lang#9386 rust-lang#9386 introduced a potential out-of-bounds array access. Specifically, a location returned by `local_assignments` could have [`location.statement_index` equal to `mir.basic_blocks[location.block].statements.len()`](https://github.com/rust-lang/rust-clippy/blob/b8a9a507bf9e3149d287841454842116c72d66c4/clippy_utils/src/mir/mod.rs#L129), in which case the location would refer to the block terminator: https://github.com/rust-lang/rust-clippy/blob/b8a9a507bf9e3149d287841454842116c72d66c4/clippy_lints/src/dereference.rs#L1204-L1206 I suspect the bug is not triggerable now, because of checks leading up to where it occurs. But a future code change could make it triggerable. Hence, it should be fixed. r? `@Jarcho` changelog: none
Standard is now uppercase in the base64 module, and from_base64 now returns a Result