is there a way to inpect the traits an object provides at runtime. Similar to pythons dir()? I wish to inspect the contents of a core::str::StrSplits<'_> and would like to be able to view the traits it implements.
There is no facility for doing this at runtime; at compile time, however, there is, and this is what rustdoc does.
With that you can see things like the core::str::StrSplits documentation which covers the information you requested.
Related
With Rust Procedural macros, developer are able to parse the TokenTree of Rust code, such as the contents of a struct. But if this struct is from another crate there does not seem to be a direct solution to implement a macro to parse it.
There is an incredibly verbose thread on the Rust Forum here related to the orphan-impl problem in Rust which does not seem to have an official conclusion. There are libraries out in the wild which do their best given the tools provided by the Rust ecosystem such as serde's remote-derive with relevant code. This though necessitates the user to define structs from external crates in their own, which makes coupling with other crates very fragile.
Example usage for serde's remote linting can be found here:
serde remote linting
Wondering if there are any different methods to solve this use case in the rust ecosystem or if there are plans in the rust core team for the future.
I have a program that I've written in Rust and I would like document it. I've looked on line and found:
https://doc.rust-lang.org/stable/rust-by-example/meta/doc.html
https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#appendix-a-full-conventions-text
I've added doc comments to the code:
/// This is a documented function
fn example() {
println!("Hi there");
}
The problem I'm having now is that after I run cargo doc, I get all the other documentation generated for all the crates my program uses, but the HTML documentation does not induce my program. I've been looking around and I haven't see anything that talks about just documenting a single program, usually I see material about documenting crates. If I can use Rust's documentation system for a stand alone program, how would can I do this?
The problem is that your function is private (which makes sense for a binary crate). However, rustdoc currently only documents public items by default (which makes sense for a library crate). You can use the flag --document-private-items to also include private functions and the like:
cargo doc --document-private-items
There is some discussion about this feature and the default we should be using here.
Furthermore, I recently opened a PR to change the default behavior for binary crates, so that private item for binary crates are documented by default. This change is expected to arrive on the stable compiler on January the 31st 2020 (1.41.0).
Is there any reason for me to use the Hash abstraction of sr-primitives instead of using the substrate_primitives::hash and substrate_primitives::hashing modules?
It's just that it seems much easier to include H256 in my code (and use the corresponding hashing functions) than to use the Hash trait.
Substrate is built to be generic and highly customizable. When you write your modules and runtime logic around the Hash trait, you gain the benefits of your module being generic over the specific type of Hash being used in the runtime.
In this case, you do not need to depend on a specific type in your runtime like H256. Instead, you have the ability to write runtime logic which only depends on the properties of a Trait. That means, if at some later point, you wanted to implement a different hash function which results in a different Hash type, you would not have to rewrite any code.
Additionally, if you plan on sharing the modules you develop with others, you will want to keep your module as generic as possible as to not force the end blockchain developer to conform to your standards.
These abstractions do add some complexity, and is not strictly needed to make things work. However, it is best practice, and something you might find pays dividends in the long term.
I'd like to use WebGL Extensions from within Rust code that is compiled to WebAssembly. The web_sys::WebGlRenderingContext has a method get_extension which returns a JsValue.
I expect there is a way to either use the dyn_into method to get an ANGLE_instanced_arrays interface, which according to this webidl may be included in web_sys somewhere, but I can't seem to get at it. If it's not possible to get to the ANGLE_instanced_arrays interface, is it possible to call known methods and properties using the JsValue directly?
I noticed that you also posted your question on the wasm-bindgen issues log where they provided some useful information. For other people who come across this I thought I would share the link.
https://github.com/rustwasm/wasm-bindgen/issues/1257
As per this issue: wasm-bindgen issue 893 - Figure out how to support interfaces with NoInterfaceObject attribute The WebGL extensions should be available in the next release.
The lexer/parser file located here is quite large and I'm not sure if it is suitable for just retrieving a list of Rust functions. Perhaps writing my own/using another library would be a better route to take?
The end objective would be to create a kind of execution manager. To contextualise, it would be able to read a list of function calls wrapped in a function. The function calls that are within the function will then be able to be re/ordered from some web interface. Thought it might be nice to manage larger applications this way.
No. I mean, not really. Whether you write your own parser or re-use syntex, you're going to hit a fundamental limitation: macros.
So let's say you go all-out and expand macro_rules!-based macros, including the ones defined in external crates (which means you'll also need to extract rustc's crate metadata loading... which isn't stable). What about procedural macros and custom derive attributes? Those are defined in code and depend on compiler-internal interfaces to function.
The only way this is likely to ever work correctly is if you build on top of the compiler, or duplicate a huge amount of work (which also involves unstable binary interfaces).
You could use syntex to parse the Rust code in a build script.