Comments (14)
It looks like there is an upstream issue about this yaahc/displaydoc#46, but it seems like this shouldn't be an issue for dependents as long as displaydoc
is on edition < 2024.
from rust.
It is expected for the non_local_definitions
lint to lint on macro-generated code.
It is also expected for the lint to lint on all editions (it is not a edition dependent lint).
from rust.
What am I meant to do as a downstream of a macro crate that hasn't fixed it then? I don't want to be #[allow]
ing a FCW, but there's nothing else I can do to clear this warning from my code. (And that implies that the planned "hard error in 2027" actually means for all editions, not just Edition 2027?)
from rust.
What am I meant to do as a downstream of a macro crate that hasn't fixed it then?
Allow the lint. Report the issue upstream. Consider switching to an unaffected crate.
I don't want to be
#[allow]
ing a FCW
That's understandable, but until the upstream crate is fixed I don't have a better solution.
Note, that it is quite unlikely that this point that the lint will become deny-by-default in Rust 2024.
(And that implies that the planned "hard error in 2027" actually means for all editions, not just Edition 2027?)
No, if hard-error there is, it would only be for edition 2027 and higher, not below.
from rust.
It is expected for the non_local_definitions lint to lint on macro-generated code.
Why?
from rust.
Detecting and ignoring macro-generated code for a lint where possible is the expected behavior of rustc.
from rust.
Because, in particular for macro-generated code, we can't lint at the source since, well it is only generated when using the proc-macro or macro_rules!
.
Detecting and ignoring macro-generated code for a lint where possible is the expected behavior of rustc.
Yes, but we must still emit the warning in macro-generated code, since the goal is to make the lint deny-by-default and then hard-error in a future edition, and without the warn it would go straight to hard-error which is not good.
from rust.
Because, in particular for macro-generated code, we can't lint at the source since, well it is only generated when using the proc-macro or
macro_rules!
.
macro authors write tests.
from rust.
Is there no ability to enable the lint when in the same crate/workspace but disable it for "foreign" macro-generated spans?
from rust.
macro authors write tests.
Yes, but can't rely on this. Also, not all macros have tests. The lint is only warn-by-default so it wouldn't break any test yet.
Is there no ability to enable the lint when in the same crate/workspace?
If you mean: "don't lint on external macro", that is possible for macro_rules!
but not for proc-macro since they are always external.
We did an crater run, to evaluate the impact, before merging the lint in #120393 (comment). We had many cases with derive-macro, most of them (82.2%) where fixable by a cargo update
, the rest would need manual intervention, the crate in question here displaydoc
was detected, and I reported the issue upstream with the fix that would fix the issue.
from rust.
If you mean: "don't lint on external macro", that is possible for macro_rules! but not for proc-macro since they are always external.
that was why I was thinking of trying to reason cross-workspace, but hmm, true.
And actually, proc macros are worse: they can either generate spans or assign themselves arbitrary spans, so at least some are going to almost certainly slip through either way.
from rust.
that was why I was thinking of trying to reason cross-workspace, but hmm, true.
I would love if we had the ability to do that, but unfortunately rustc
doesn't have that information. Workspaces are a Cargo-only concept.
And actually, proc macros are worse: they can either generate spans or assign themselves arbitrary spans, so at least some are going to almost certainly slip through either way.
👀
from rust.
I would love if we had the ability to do that, but unfortunately rustc doesn't have that information. Workspaces are a Cargo-only concept.
I was hoping that we could do something where cargo helps us out here by describing which things we pay attention to, but I am fully prepared to believe that such is not tractable, even if only because no one has figured out if the infra for doing such a thing is even possible.
from rust.
Yeah, unfortunately there isn't really anything else the compiler can do, it would be great if we could lint at the macro definition but due to the way they work that isn't possible, we are therefore forced to do the second "best" thing and lint at the usage.
#125722 should be make it clearer that the "macro needs to change".
So let's reclassify this issue as not-a-bug but as a discussion.
@rustbot labels -C-bug +C-discussion
from rust.
Related Issues (20)
- rustdoc leaks private types in Implementations on Foreign Types HOT 1
- bootstrap: `profile = "tools"` contains incompatible options. HOT 2
- ICE "Failed to extract DefId" HOT 1
- Request for `tune-cpu` code generation option to be promoted to stable HOT 2
- ICE: `ConstArgHasType(^0, usize)` has escaping bound vars, so it cannot be wrapped in a dummy binder. HOT 2
- ICE: `only 'variances_of' returns '&[ty::Variance]'`
- ICE. `try_from_lit: received const param which shouldn't be possible` HOT 3
- unreachable!("state is never set to invalid values") is reached HOT 53
- ICE in the face of malformed code HOT 2
- array::IntoIter::new deprecation warning suggestion may lead to compilation error on 2015 and 2018 editions HOT 2
- CStr::from_ptr() crashes the program with a segfault when loading a string from memory after passing it in a global_asm!() function. HOT 6
- `tool::prepare_tool_cargo` should run `builder.ensure` automatically, based on tool mode HOT 4
- ICE: `adding a def'n for node-id NodeId(18) and def kind AnonConst but a previous def'n exists` HOT 9
- Doctests cannot recognize paths that lead to a type in the crate root HOT 3
- `./x check std` should not try to check `no_std` targets HOT 2
- Tracking Issue for unsized const parameter types: `feature(unsized_const_params)`
- Some invalid cargo cache data leads to ICE
- Goofy suggestion when trying to use a raw ptr receiver and also the self keyword in the body HOT 1
- Tracking Issue for Contracts
- Vetting 3rd party crates for supply-chain-security issues
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust.