Conversation
| } | ||
|
|
||
| /// Handler implementations provided by the language runtime. | ||
| pub struct Handlers { |
There was a problem hiding this comment.
These new structs fix the "too many arguments" lint.
e48aaf4 to
6b7a977
Compare
crates/amalthea/src/socket/comm.rs
Outdated
| } | ||
|
|
||
| /// Send an outgoing comm message through IOPub. | ||
| #[allow(clippy::result_large_err)] |
There was a problem hiding this comment.
This is probably one I would perma-allow in Cargo.toml
There was a problem hiding this comment.
There was a problem hiding this comment.
Looks like individual crates can re-opt into lints disabled at workspace level if needed, so that approach sounds good to me
crates/amalthea/src/comm.rs
Outdated
| #[allow(clippy::large_enum_variant)] | ||
| pub mod data_explorer_comm; |
There was a problem hiding this comment.
As of late last year, clippy has gained expect() rather than allow() which I think is quite nice.
https://users.rust-lang.org/t/dont-allow-expect-and-be-reasonable/136078
allow() says "if there is a problem, ignore it"
expect() says "there is a problem, ignore it, but also let me know if it isnt there anymore", which allows you to remove the expect() if it goes away at some point in the future
There was a problem hiding this comment.
Switching to expect() already allowed finding some dangling opt-outs for deref lints, following the SEXP repr PR!
crates/amalthea/src/kernel.rs
Outdated
| iopub_tx: Sender<IOPubMessage>, | ||
| iopub_rx: Receiver<IOPubMessage>, | ||
| comm_event_rx: Receiver<CommEvent>, | ||
| // Receiver channel for the stdin socket; when input is needed, the | ||
| // language runtime can request it by sending an StdInRequest::Input to | ||
| // this channel. The frontend will prompt the user for input and | ||
| // the reply will be delivered via `stdin_reply_tx`. | ||
| // https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-stdin-router-dealer-channel. | ||
| // Note that we've extended the StdIn socket to support synchronous requests | ||
| // from a comm, see `StdInRequest::Comm`. | ||
| stdin_request_rx: Receiver<StdInRequest>, | ||
| // Transmission channel for StdIn replies | ||
| stdin_reply_tx: Sender<crate::Result<InputReply>>, | ||
| channels: ConnectionChannels, | ||
| ) -> Result<(), Error> { | ||
| let Handlers { | ||
| shell_handler, | ||
| control_handler, | ||
| server_handlers, | ||
| } = handlers; | ||
| let ConnectionChannels { | ||
| iopub_tx, | ||
| iopub_rx, | ||
| comm_event_rx, | ||
| stdin_request_rx, | ||
| stdin_reply_tx, | ||
| } = channels; |
There was a problem hiding this comment.
To me, packing and immediately unpacking is more noise, and I'd just ignore clippy here.
There was a problem hiding this comment.
I don't know, if feels a bit more tidy to me.
Although the unpacking is unnecessary, I'll remove it
| R_INIT.set(()).expect("`R_INIT` can only be set once"); | ||
| } | ||
|
|
||
| #[allow(clippy::too_many_arguments)] |
There was a problem hiding this comment.
I would personally perma ignore, I can decide if it is too many arguments or not 😛
There was a problem hiding this comment.
I don't feel strongly either way so I'll perma-ignore.
I do like packed arguments in the kernel connection entry points as it makes call sites easier to read and understand. But I can see cases where that doesn't make sense.
| NULL, | ||
| NA, | ||
| NaN, | ||
| Null, | ||
| Na, | ||
| Nan, |
There was a problem hiding this comment.
Booo I like mimicking the R values!
| // /// Move this cursor to the node that is at or closest to (but not after) | ||
| // /// the requested point. | ||
| // /// | ||
| // /// Returns `false` if the cursor is after the `point`. | ||
| // /// | ||
| // /// TODO: It would be nice to use this, but there is a bug in tree sitter | ||
| // /// that makes it impossible right now: | ||
| // /// https://github.com/tree-sitter/tree-sitter/issues/2767 | ||
| // /// For now, use `node.find_closest_node_for_point()`. |
There was a problem hiding this comment.
I think you meant to remove a / not add more
There was a problem hiding this comment.
nope I actually commented out the docstring
crates/ark/src/lsp/traits/point.rs
Outdated
| // Point is a small Copy type, so it's fine to pass by value | ||
| #[allow(clippy::wrong_self_convention)] |
There was a problem hiding this comment.
it is a little weird for is_ methods though
| NodeType::UnaryOperator(op) => match op { | ||
| UnaryOperatorType::Tilde => recurse_formula(node, context, diagnostics), | ||
| _ => recurse_default(node, context, diagnostics), | ||
| NodeType::UnaryOperator(UnaryOperatorType::Tilde) => { | ||
| recurse_formula(node, context, diagnostics) | ||
| }, | ||
| NodeType::UnaryOperator(_) => recurse_default(node, context, diagnostics), |
There was a problem hiding this comment.
im not really sure if i like that
| sizeof_node: usize, | ||
| sizeof_vector: usize, | ||
| seen: &mut HashSet<SEXP>, | ||
| depth: u32, |
There was a problem hiding this comment.
Should this have been used?
There was a problem hiding this comment.
In lobstr it's only used in debugging print statements that are commented out.
| @@ -45,7 +46,7 @@ macro_rules! generate { | |||
| $(#[doc=$doc])* | |||
| $(#[cfg($cfg)])* | |||
| pub fn $name() -> bool { | |||
| unsafe { matches!([<$name _opt>], Some(_)) } | |||
| unsafe { (*std::ptr::addr_of!([<$name _opt>])).is_some() } | |||
There was a problem hiding this comment.
What is clippy upset about here? This seems fine to me.
Is it possible to leave this and functions.rs as is for now?
There was a problem hiding this comment.
The current versions are accessing static mut references, which the Rust community has been trying to phase out (rust-lang/rust#53639). The new ones are creating raw pointers instead, to be accessed by unsafe code.
Since you wrote these macros I've reverted, but I'd have kept the new versions I think.
There was a problem hiding this comment.
Actually the switch to is_some() creates a reference that is linted by rustc, not just clippy. I'd keep the new versions.
491100b to
7de2cc8
Compare
As of late last year, clippy has gained expect() rather than allow() which I think is quite nice. https://users.rust-lang.org/t/dont-allow-expect-and-be-reasonable/136078 allow() says "if there is a problem, ignore it" expect() says "there is a problem, ignore it, but also let me know if it isnt there anymore", which allows you to remove the expect() if it goes away at some point in the future
Fixes:
warning: creating a shared reference to mutable static
--> crates/libr/src/functions.rs:46:25
|
46 | [<$name _opt>].is_some()
| ^^^^^^^^^^^^^^ shared reference to mutable static
|
::: crates/libr/src/r.rs:21:1
|
21 | / functions::generate! {
22 | | pub fn R_NewEnv(enclos: SEXP, hash: std::ffi::c_int, size:
std::ffi::c_int) -> SEXP;
23 | |
24 | | pub fn R_ParentEnv(x: SEXP) -> SEXP;
... |
444 | | }
| |_- in this macro invocation
6b7a977 to
529fc05
Compare
Branched from #1108
Progress towards #1104
Main lints fixed:
&strinstead of&String,&Pathinstead of&PathBuf,&[]instead of&VecEOF, so they've become e.g.EndOfFileDidprefix, e.g.KernelNotification::DidOpenVirtualDocument.into_methods must takeself. Renamed those that didn't, e.g.Dap::make_variables()which is not really an "into" method strictly speaking.match.is_some()oris_err()methods when applicable?instead of explicitreturnwhen applicable