Merge branch 'xMAC94x/prepare_toolchain_upgrade' into 'master'

prepare comments intendation for next toolchain

See merge request veloren/veloren!4519

client/i18n/src/lib.rs

@@ -424,12 +424,10 @@ impl LocalizationGuard {
     /// 1) Because content we want is localized itself and has arguments, we
     ///    iterate over them and localize, recursively. Having that, we localize
     ///    our content.
-    ///
+    /// 2) Now there is a chance that some of args have missing internalization.
-    /// 2) Now there is a chance that some of args have missing
+    ///    In that case, we insert arg name as placeholder and mark it as
-    /// internalization. In that case, we insert arg name as placeholder and
+    ///    broken. Then we repeat *whole* procedure on fallback language if we
-    /// mark it as broken. Then we repeat *whole* procedure on fallback
+    ///    have it.
-    /// language if we have it.
-    ///
     /// 3) Otherwise, return result from (1).
     // NOTE: it's important that we only use one language at the time, because
     // otherwise we will get partially-translated message.

client/src/lib.rs

@@ -3331,6 +3331,7 @@ mod tests {
     /// CHANGING IT WILL BREAK 3rd PARTY APPLICATIONS (please extend) which
     /// needs to be informed (or fixed)
     ///  - torvus: https://gitlab.com/veloren/torvus
+    ///
     /// CONTACT @Core Developer BEFORE MERGING CHANGES TO THIS TEST
     fn constant_api_test() {
         use common::clock::Clock;

common/base/src/userdata_dir.rs

@@ -20,6 +20,7 @@ const VELOREN_USERDATA_ENV: &str = "VELOREN_USERDATA";
 ///   1. The VELOREN_USERDATA environment variable
 ///   2. The VELOREN_USERDATA_STRATEGY environment variable
 ///   3. The CARGO_MANIFEST_DIR/userdata or CARGO_MANIFEST_DIR/../userdata
+///
 /// depending on if a    workspace if being used
 pub fn userdata_dir(workspace: bool, strategy: Option<&str>, manifest_dir: &str) -> PathBuf {
     // 1. The VELOREN_USERDATA environment variable

common/ecs/src/system.rs

@@ -45,12 +45,11 @@ impl Origin {
 pub struct CpuTimeline {
     /// measurements for a System
     /// - The first entry will always be ParMode::Single, as when the
-    ///   System::run is executed, we run
+    ///   System::run is executed, we run single threaded until we start a
-    /// single threaded until we start a Rayon::ParIter or similar
+    ///   Rayon::ParIter or similar
     /// - The last entry will contain the end time of the System. To mark the
-    ///   End it will always contain
+    ///   End it will always contain ParMode::None, which means from that point
-    /// ParMode::None, which means from that point on 0 CPU threads work in this
+    ///   on 0 CPU threads work in this system
-    /// system
     measures: Vec<(Instant, ParMode)>,
 }
 

common/frontend/src/lib.rs

@@ -27,6 +27,7 @@ const RUST_LOG_ENV: &str = "RUST_LOG";
 ///  - warn for `prometheus_hyper`, `dot_vox`, `gfx_device_gl::factory,
 ///    `gfx_device_gl::shade` trace for `veloren_voxygen`, info for everything
 ///    else
+///
 /// `RUST_LOG="prometheus_hyper=warn,dot_vox::parser=warn,gfx_device_gl::
 /// factory=warn,gfx_device_gl::shade=warn,veloren_voxygen=trace,info"`
 ///

common/net/src/msg/world_msg.rs

@@ -48,9 +48,9 @@ pub struct WorldMapMsg {
     /// 1. they have no gaps, so as soon as light can shine through it will
     ///    always be able to do so, and
     /// 2. we only care about lighting from the top, and only from the east and
-    /// west    (since at a large scale like this we mostly just want to
+    ///    west (since at a large scale like this we mostly just want to handle
-    /// handle variable sunlight;    moonlight would present more challenges
+    ///    variable sunlight; moonlight would present more challenges but we
-    /// but we currently have no plans to try to cast    accurate shadows in
+    ///    currently have no plans to try to cast accurate shadows in
     ///    moonlight).
     ///
     /// Our chosen format is two pairs of vectors,

common/src/clock.rs

@@ -10,11 +10,13 @@ use std::{
 /// - if we actually took less time than we planned: sleep and return planned
 ///   time
 /// - if we ran behind: don't sleep and return actual time
+///
 /// We DON'T do any fancy averaging of the deltas for tick for 2 reasons:
 ///  - all Systems have to work based on `dt` and we cannot assume that this is
 ///    const through all ticks
 ///  - when we have a slow tick, a lag, it doesn't help that we have 10 fast
 ///    ticks directly afterwards
+///
 /// We return a smoothed version for display only!
 pub struct Clock {
     /// This is the dt that the Clock tries to archive with each call of tick.

common/src/comp/fluid_dynamics.rs

@@ -387,13 +387,12 @@ pub fn zero_lift_drag_coefficient() -> f32 { 0.026 }
 /// Does not apply to twisted, cambered or delta wings. (It still gives a
 /// reasonably accurate approximation if the wing shape is not truly
 /// elliptical.)
-/// 1. geometric angle of attack, i.e. the pitch angle relative to
+///   1. geometric angle of attack, i.e. the pitch angle relative to freestream
-/// freestream flow
+///      flow
 ///   2. up to around ~18°, at which point maximum lift has been achieved and
 ///      thereafter falls precipitously, causing a stall (this is the stall
 ///      angle)
-/// 3. effective aoa, i.e. geometric aoa - induced aoa; assumes
+///   3. effective aoa, i.e. geometric aoa - induced aoa; assumes no sideslip
-/// no sideslip
 // TODO: Look into handling tapered wings
 fn lift_slope(aspect_ratio: f32, sweep_angle: Option<f32>) -> f32 {
     // lift slope for a thin aerofoil, given by Thin Aerofoil Theory

common/src/comp/inventory/item/mod.rs

@@ -468,8 +468,7 @@ pub struct Item {
     ///   slot shapes
     /// - Modular components should agree with the tool kind
     /// - There should be exactly one damage component and exactly one held
-    ///   component for modular
+    ///   component for modular weapons
-    /// weapons
     components: Vec<Item>,
     /// amount is hidden because it needs to maintain the invariant that only
     /// stackable items can have > 1 amounts.

common/src/typed.rs

@@ -25,8 +25,8 @@ pub trait Typed<Context, Type, S> {
 /// - For enums, we synthesize a match on the current head.  For each match arm,
 ///   we then repeat this process on the constructor arguments; if there are no
 ///   constructor arguments, we synthesize a literal (Pure term). (TODO: Handle
-///   > 1 tuple properly--for now we just synthesize a Pure term for these
+///   larger than 1 tuple properly--for now we just synthesize a Pure term for
-///   cases).
+///   these cases).
 ///
 /// - For structs, we synthesize a projection on the current head.  For each
 ///   projection, we then repeat this process on the type of the projected

network/src/participant.rs

@@ -638,14 +638,12 @@ impl BParticipant {
     /// on the remote, we have a timeout to also force close AR.
     ///
     /// This fn will:
-    ///  - 1. stop api to interact with bparticipant by closing sendmsg and
+    ///   1. stop api to interact with bparticipant by closing sendmsg and
     ///      openstream
-    ///  - 2. stop the send_mgr (it will take care of clearing the
+    ///   2. stop the send_mgr (it will take care of clearing the queue and
-    /// queue and finish with a Shutdown)
+    ///      finish with a Shutdown)
-    ///  - (3). force stop recv after 60
+    ///   3. force stop recv after 60 seconds
-    /// seconds
+    ///   4. this fn finishes last and afterwards BParticipant drops
-    ///  - (4). this fn finishes last and afterwards BParticipant
-    /// drops
     ///
     /// before calling this fn, make sure `s2b_create_channel` is closed!
     /// If BParticipant kills itself managers stay active till this function is

network/tests/closing.rs

@@ -9,6 +9,7 @@
 //!      - 2 networks
 //!      - 2 participants
 //!      - 2 streams
+//!
 //!    each one `linked` to their counterpart.
 //!    You see a cryptic use of rust `_` this is because we are testing the
 //!    `drop` behavior here.

server/src/cmd.rs

@@ -108,7 +108,7 @@ type CmdResult<T> = Result<T, Content>;
 ///   This differs from the previous argument when using /sudo
 /// * `Vec<String>` - a `Vec<String>` containing the arguments of the command
 ///   after the keyword.
-/// * `&ChatCommand` - the command to execute with the above arguments.
+/// * `&ChatCommand` - the command to execute with the above arguments --
 ///   Handler functions must parse arguments from the the given `String`
 ///   (`parse_args!` exists for this purpose).
 ///

server/src/settings/editable.rs

@@ -180,12 +180,11 @@ pub trait EditableSetting: Clone + Default {
     /// * If e is Integrity, validation failed and the settings were not
     ///   updated.
     /// * If e is Io, validation succeeded and the settings were updated in
-    ///   memory, but they
+    ///   memory, but they could not be saved to storage (and a warning was
-    /// could not be saved to storage (and a warning was logged).  The reason we
+    ///   logged). The reason we return an error even though the operation was
-    /// return an error even though the operation was partially successful
+    ///   partially successful is so we can alert the player who ran the command
-    /// is so we can alert the player who ran the command about the failure,
+    ///   about the failure, as they will often be an administrator who can
-    /// as they will often be an administrator who can usefully act upon that
+    ///   usefully act upon that information.
-    /// information.
     #[must_use]
     fn edit<R>(
         &mut self,

server/src/sys/terrain.rs

@@ -360,9 +360,8 @@ impl<'a> System<'a> for Sys {
                 // using eg. /reload_chunks
 
                 // TODO: code duplication for chunk insertion between here and state.rs
-                data.terrain.remove(key).map(|chunk| {
+                data.terrain.remove(key).inspect(|_| {
                     data.terrain_changes.removed_chunks.insert(key);
-                    chunk
                 })
             })
             .collect::<Vec<_>>();

server/src/terrain_persistence.rs

@@ -329,11 +329,12 @@ impl ByBlockLimiter {
 /// The steps for doing this are as follows:
 ///
 /// 1. Create a new 'raw format' type that implements [`Serialize`] and
-/// `Deserialize`]. Make sure to add a version field. If in doubt, copy the last
+///    `Deserialize`]. Make sure to add a version field. If in doubt, copy the
-/// raw format and increment the version number wherever it appears. Don't
+///    last raw format and increment the version number wherever it appears.
-/// forget to increment the version number in the `serde(deserialize_with =
+///    Don't forget to increment the version number in the
-/// ...}` attribute! Conventionally, these types are named `V{N}` where `{N}` is
+///    `serde(deserialize_with = ...}` attribute! Conventionally, these types
-/// the number succeeding the previous raw format type.
+///    are named `V{N}` where `{N}` is the number succeeding the previous raw
+///    format type.
 ///
 /// 2. Add an implementation of `From<{YourRawFormat}>` for `Chunk`. As before,
 ///    see previous versions if in doubt.

voxygen/src/audio/music.rs

@@ -139,15 +139,6 @@ enum DayPeriod {
     Night,
 }
 
-/// Determines whether the sound is stopped, playing, or fading
-#[derive(Debug, Deserialize, PartialEq)]
-enum PlayState {
-    Playing,
-    Stopped,
-    FadingOut,
-    FadingIn,
-}
-
 /// Provides methods to control music playback
 pub struct MusicMgr {
     /// Collection of all the tracks

voxygen/src/audio/sfx/event_mapper/block/mod.rs

@@ -283,11 +283,11 @@ impl BlockEventMapper {
     /// Ensures that:
     /// 1. An sfx.ron entry exists for an SFX event
     /// 2. The sfx has not been played since it's timeout threshold has elapsed,
-    /// which prevents firing every tick
+    ///    which prevents firing every tick. Note that with so many blocks to
-    /// Note that with so many blocks to choose from and different blocks being
+    ///    choose from and different blocks being selected each time, this is
-    /// selected each time, this is not perfect, but does reduce the number of
+    ///    not perfect, but does reduce the number of plays from blocks that
-    /// plays from blocks that have already emitted sfx and are stored in the
+    ///    have already emitted sfx and are stored in the BlockEventMapper
-    /// BlockEventMapper history.
+    ///    history.
     fn should_emit(
         previous_state: &PreviousBlockState,
         sfx_trigger_item: Option<(&SfxEvent, &SfxTriggerItem)>,

voxygen/src/audio/sfx/event_mapper/movement/mod.rs

@@ -159,9 +159,10 @@ impl MovementEventMapper {
     /// When specific entity movements are detected, the associated sound (if
     /// any) needs to satisfy two conditions to be allowed to play:
     /// 1. An sfx.ron entry exists for the movement (we need to know which sound
-    /// file(s) to play) 2. The sfx has not been played since it's timeout
+    ///    file(s) to play)
-    /// threshold has elapsed, which prevents firing every tick. For movement,
+    /// 2. The sfx has not been played since it's timeout threshold has elapsed,
-    /// threshold is not a time, but a distance.
+    ///    which prevents firing every tick. For movement, threshold is not a
+    ///    time, but a distance.
     fn should_emit(
         previous_state: &PreviousEntityState,
         sfx_trigger_item: Option<(&SfxEvent, &SfxTriggerItem)>,

voxygen/src/mesh/greedy.rs

@@ -286,7 +286,7 @@ impl AtlasAllocator for GuillotiereTiled {
             tracing::trace!("Packing ratio: {}", total_area as f32 / total_used as f32);
         }
 
-        let diff = (new_size - self.size()).map(|e| e.max(0));
+        let diff = new_size.map2(self.size(), |n, s| n.saturating_sub(s));
         // NOTE: Growing only occurs in increments of TILE_SIZE so any remaining size is
         // ignored. Max size is not known here so this must truncate instead of rounding
         // up.

voxygen/src/scene/camera.rs

@@ -95,13 +95,13 @@ fn clamp_and_modulate(ori: Vec3<f32>) -> Vec3<f32> {
 ///   depth planes go from 1 to 0, meaning f = near and n = far, aka "reverse
 ///   depth").
 ///
-///     This is by far the most
+/// This is by far the most likely thing to want to change; inverted depth
-///     likely thing to want to change; inverted depth coordinates have *far*
+/// coordinates have *far* better accuracy for DirectX / Metal / WGPU-like
-/// better accuracy for     DirectX / Metal / WGPU-like APIs, when using
+/// APIs, when using floating point depth, while not being *worse* than the
-/// floating point depth, while not being *worse*     than the alternative
+/// alternative (OpenGL-like depth, or when using fixed-point / integer depth).
-/// (OpenGL-like depth, or when using fixed-point / integer depth).  For
+/// For maximum benefit, make sure you are using Depth32F, as on most
-///     maximum benefit, make sure you are using Depth32F, as on most platforms
+/// platforms this is the only depth buffer size where floating point can be
-/// this is the only     depth buffer size where floating point can be used.
+/// used.
 ///
 /// It is a bit unintuitive to prove this, but it turns out that when using
 /// 1 to 0 depth planes, the point where the depth buffer has its worst
@@ -207,7 +207,7 @@ fn clamp_and_modulate(ori: Vec3<f32>) -> Vec3<f32> {
 /// ```
 ///
 /// One thing you may notice is that this worst-case bound *does not depend
-/// on the near plane.*     This means that (within reason) you can put the near
+/// on the near plane.*This means that (within reason) you can put the near
 /// plane as close as you like and still attain this bound.  Of course, the
 /// bound is not completely tight, but it should not be off by more than a
 /// factor of 2 or so (informally proven, not made rigorous yet), so for most

voxygen/src/scene/figure/load.rs

@@ -423,9 +423,6 @@ impl_concatenate_for_wrapper!(HumArmorFootSpec);
 struct HumMainWeaponSpec(HashMap<ToolKey, ArmorVoxSpec>);
 impl_concatenate_for_wrapper!(HumMainWeaponSpec);
 #[derive(Deserialize)]
-struct HumModularComponentSpec(HashMap<String, ModularComponentSpec>);
-impl_concatenate_for_wrapper!(HumModularComponentSpec);
-#[derive(Deserialize)]
 struct HumArmorLanternSpec(ArmorVoxSpecMap<String, ArmorVoxSpec>);
 impl_concatenate_for_wrapper!(HumArmorLanternSpec);
 #[derive(Deserialize)]

voxygen/src/session/interactable.rs

@@ -119,6 +119,7 @@ impl Interactable {
 ///   a) entity (if within range)
 ///   b) collectable
 ///   c) can be mined, and is a mine sprite (Air) not a weak rock.
+///
 /// 2) outside of targeted cam ray
 ///   -> closest of nearest interactable entity/block
 pub(super) fn select_interactable(

voxygen/src/singleplayer/singleplayer_world.rs

@@ -9,13 +9,6 @@ use serde::{Deserialize, Serialize};
 use server::{FileOpts, GenOpts, DEFAULT_WORLD_MAP, DEFAULT_WORLD_SEED};
 use tracing::error;
 
-#[derive(Clone, Deserialize, Serialize)]
-struct World0 {
-    name: String,
-    gen_opts: Option<GenOpts>,
-    seed: u32,
-}
-
 pub struct SingleplayerWorld {
     pub name: String,
     pub gen_opts: Option<GenOpts>,

world/src/layer/spot.rs

@@ -24,10 +24,8 @@ use vek::*;
 /// To add a new spot, one must:
 ///
 /// 1. Add a new variant to the [`Spot`] enum.
-///
 /// 2. Add a new entry to [`Spot::generate`] that tells the system where to
 ///    generate your new spot.
-///
 /// 3. Add a new arm to the `match` expression in [`Spot::apply_spots_to`] that
 ///    tells the generator how to generate a spot, including the base structure
 ///    that composes the spot and the entities that should be spawned there.