This only shows the warnings when deprecated commands' definitions are parsed and not on calls to the deprecated commands right?

I like the idea of @deprecated and the refactors you made, but I think we first need a way to properly handle deprecation warnings. If we decide to deprecate a command in std and use @deprecated as it is now, rather than users getting warned when they use deprecated commands, they will be warned when they import modules that contain deprecated commands.

I looked around a bit to see what's usually done when built-in commands are deprecated and they just throw a warning each time they are called and then run as usual.
I think we need a different approach where deprecated commands (let's say they are just marked by changing their category to deprecated) throw a warning when they are first called. And by called I don't mean when they run, I mean when they appear in parsed code.

# aaa.nu
@deprecated
export def foo [] { ... }

# bbb.nu
use aaa.nu
export def bar [] {
    foo
}

# repl

❯ use aaa.nu
# no warning

❯ use bbb.nu
# warning is thrown since

they will be warned when they import modules that contain deprecated commands

whoops, not sure how that slipped my mind. this definitely needs to happen when parsing a call, not when parsing the definition

throw a warning when they are first called

this is definitely needed, we discussed this before in the context of table->render and also lints, although i don't think we need that for an initial implementation necessary

let's say they are just marked by changing their category to deprecated

i think we need something more complex than this so we can have a message still. maybe @deprecated can just be a normal attribute, and then we check for the @deprecated attribute when we parse a call?

Yeah, a normal attribute makes more sense than a category for this since it can also store a message.

We can add a Command::is_deprecated() that for BlockCommand's is based on their attributes and can be manually implemented for built-ins.

just updated the PR with your suggest @Bahex. also added a "report log" (thread-global, rather than in EngineState) which lets us make sure we only report deprecation warnings (and later, lints if we decide to add those) once. It needs to be in the reporting code since we might generate the warning without reporting it (for example, while typing the command in the REPL). I'm not sure about storing the DeclId in the error itself, but it seems to be the only place which really makes sense

this is almost ready, just need to move the ReportLog to EngineState and also investigate how difficult it would be to expose the deprecation stuff to plugins

this is ready now, I moved the report log into EngineState. I investigated if it would be possible to make this available to plugins, and I think it should be possible by implementing deprecation_info for PluginDeclaration? I think we would have to store deprecation status as part of the plugin registry in order for that to work unfortunately (since we don't want to load the plugin just for deprecation status during parse-time), and that's a bit more than I can do at the moment, but I might try to revisit this later (or if anyone else wants to implement it that would also be great)

should be good to (re-)review @cptpiepmatz and @Bahex if you'd like to take a look