Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow unused definitions #52

Closed
Tehforsch opened this issue Jan 4, 2024 · 0 comments · Fixed by #73
Closed

Allow unused definitions #52

Tehforsch opened this issue Jan 4, 2024 · 0 comments · Fixed by #73
Labels
code-quality enhancement New feature or request

Comments

@Tehforsch
Copy link
Owner

The unit_system macro generates the type aliases corresponding to the dimensions and the Quantity constructors corresponding to the units for every storage type. It can happen quite quickly that one defines a dimension/unit that is only used for one of the storage types. In that case, a confusing unused code warning will be emitted if the module which calls unit_system is not a public export of the current crate. Minimal example:

use diman::unit_system;

unit_system!(
    quantity_type Quantity;
    dimension_type Dimension;

    dimension Length;

    #[base(Length)]
    unit meter: Length;

);

pub fn main() {
    let x = self::f32::Length::meter(5.0);
}

With f32 and f64 features enabled, this will generate an error

warning: type alias `Length` is never used
 --> src/my_mod.rs:7:15
  |
7 |     dimension Length;
  |               ^^^^^^

I only see two simple solutions to this problem:

  1. Add #[allow(unused)] for every dimension / unit constructor.
  2. Require users to export the Quantity struct by making the module which calls unit_system a public part of the library.

Now 2. is how it currently is, but is clearly not a good solution. Implementing 1. is fine in principle, but it is a bit unfortunate that this rules out getting useful warnings that could identify unused dimensions/units.

@Tehforsch Tehforsch added enhancement New feature or request code-quality labels Jan 4, 2024
@Tehforsch Tehforsch linked a pull request Feb 25, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-quality enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant