marker

An experimental linting interface for Rust. Let's make custom lints a reality (by rust-marker)
Add to my DEV experience #Linting #Rust
Source Code
marker Reviews
Suggest alternative
Edit details
Access the most powerful time series database as a service
Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
www.influxdata.com
Sponsored

Marker Alternatives

Similar projects and alternatives to marker

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better marker alternative or higher similarity.
Suggest an alternative to marker

marker reviews and mentions

Posts with mentions or reviews of marker. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-01-25.
  • Blog Post: Next Rust Compiler
    7 projects | reddit.com/r/rust | 25 Jan 2023
    Check out this, which aims to implement said stable interface!
  • 1Password releases Typeshare, the "ultimate tool for synchronizing your type definitions between Rust and other languages for seamless FFI"
    14 projects | reddit.com/r/rust | 22 Nov 2022
    Hey, I might be able to give some input how I deal with it in [rust-linting](https://github.com/rust-linting/rust-linting). For some context, the project needs to load several dynamic libraries and provide each of them with an abstract syntax tree. Serializing and deserializing the types for every step would most likely be too expensive. That's why I opted for a Rust <-> Rust FFI. There are two parts of this: 1. The loaded libraries needed to accept data from a driver. For this, I generate functions in the library crates which are marked as `extern "C"` and only use FFI safe types. Passing information to the loaded crates then always calls the generated functions, which intern call access a thread local struct instance in the dynamic crate. It's important that the instance implement a specific trait. For the library creation, it seems like magic. 2. Callbacks. The loaded libraries need to pass information back to the driver. For this, I use a struct with function pointers. These are also marked as `extern "C"` and need to only use FFI safe types. The definition of FFI safe, is a bit difficult. Slices, `str`, `Option<>` and most of the rusts STD types don't have a stable layout to the point, that it can change between compilations with the same compiler. Therefore, it's required that each passed type is `#[repr(C)]`. Options are wrapped in an enum, which has `#[repr(C)]`, slices and strings are dismantled into a data pointer and a length. On the receiving and they're reconstructed again. A small warning. I'm not an expert on FFI interfaces. My implementation would probably have some problems with lifetimes, if I'd use a slightly different memory model. So far, this has worked well (Besides the required boilerplate). The project is currently sadly lacking documentation, as it's still under heavy development. If you want, feel free to lock around the code base. The stable types and most of the interface is inside the `linter_api` crate.

Stats

Basic marker repo stats
2
53
9.7
5 days ago

rust-marker/marker is an open source project licensed under Apache License 2.0 which is an OSI approved license.


Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com