A new proposal has been announced: Add a
NOOP_METHOD_CALL lint for methods which should never be directly called #375. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.
is there an existing clippy lint for this?
let me check
if so, I think we should uplift it
but there's no generic lint that covers other noop methods on
so, I think we could remove the clippy one if we add the rustc one
the general case sounds hard to do - would there be a fixed list of no-ops? Or would the lint look for functions implemented as the identity function?
I don't think we'd want to do any autodetection
I proposed a
#[noop] attribute in the MCP
though that doens't cover all of the cases in libstd
all of the methods I listed in the MCP are essentially the same (and any known calls to them can be removed), so I think it makes sense to have a single lint for all of them
noop doesn't really seem right for this to me.
Clone::clone(&true) is silly, but not exactly a no-op.
Trouble for the attribute: there's no specific
<&T as ToOwned>::to_owned today. That comes from the blanket
Yeah - I discussed a couple of approaches to solving that in the mcp
If we start out by just linting std types, we don't have to commit ourselves to any particular way of marking the method
Also, I'm find with calling the attr something other than
noop - it was the first thing that came to mind
There hasn't been any discussion of this for a week. Is anyone opposed to the overall concept of the lint (leaving aside the exact name and attributefor the moment)?
SGTM, but I'm still a little unclear exactly how it will be implemented. I guess that doesn't need to block the MCP though.
Since this is a new lint, does this require a T-Lang FCP?
@Aaron Hill usually we FCP the PR
but you could FCP before-hand too
Does that happen before or after it's seconded?
so I'm not sure if my script will pick up MCP changes for t-lang :)
you could file an issue and nominate it for now
we should tweak these procedures
(been on my mind to try and harmonize things a bit...)
alternatively file a lang-team proposal :)
any which way to get it on the triage meeting agenda
(gotta run now)
I'm presuming you want lang team input before you implement
Opened https://github.com/rust-lang/lang-team/issues/66 with just the lint, leaving off the specific details about how to indicate the methods (e.g.
let me know if I messed up the produce for opening these kinds of issues
@Aaron Hill ack, that was the wrong sort of proposal, so I missed it
would you object to closing and re-opening a project proposal?
should probably reorganize things a bit
will there really be a 'project group', though?
I think this lint will be very similar to https://github.com/rust-lang/rust/pull/75573 in terms of overall complexity
or have some of the procedurs changed this that PR's FCP?
no there would not be a project group
@Aaron Hill that is one of the renamings I want to do :)
the idea is just to propose "projects", often they just end with "go implement it"
only in rare cases do we need to create a whole group, though we can also create a stream if it's useful for design discussion
@Aaron Hill are you going to work on the implementation for this? This sounds interesting and I would try to take a stab at it if you're busy with other things.
@Ryan Levick I was planning to, but feel free to work on it!
@T-compiler: Proposal #375 has been seconded, and will be approved in 10 days if no objections are raised.
The implementation for this can be found here: https://github.com/rust-lang/rust/pull/80723
This proposal has been accepted: #375.