-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add known-bug tests for derive failure to detect packed repr #121025
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
5bda226
to
359b1b3
Compare
This comment was marked as resolved.
This comment was marked as resolved.
359b1b3
to
bb6330f
Compare
What will happen in a case like this? Will it still ICE? #[derive(PartialEq)]
#[proc_macro_attribute_that_generates_repr_packed]
struct Dealigned<T>(u8, T); Built-in macros are still macros, they still see their input as tokens (well, maybe as AST, but that is supposed to be an unobservable optimization). |
oh wow this has been an issue since the |
I don't see any way around that (well we could error), but the fundamental limitation is there as long as we don't expand proc macros attributes before we run the derive. |
@rustbot review I added a known-bug ICE test and marked this PR as not fixing the issue anymore. I think the diagnostic changes are still an improvement, so we may want to land it regardless? |
Yeah, the diagnostics are improved, but I'm not sure what are the full implications of updating the resolution here. So the old resolution may stuck in some places, and the new resolution in other places, and the mismatches could cause ICEs in places like import validation. |
Yea, makes sense. Do you have any ideas what we could do to taint anything in case there are name collisions? If not, let's just close this and address the ICE separately |
I need to think. |
Let's just not do this, the improvements are probably not worth the effort. |
…acked)]` attributes that are not visible before macro expansion
1f956fe
to
bed9d1f
Compare
Makes sense, thanks for checking. Kept the tests, removed the rest. @rustbot review |
@bors r+ |
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#121025 (add known-bug tests for derive failure to detect packed repr) - rust-lang#121194 (Refactor pre-getopts command line argument handling) - rust-lang#121563 (Use `ControlFlow` in visitors.) - rust-lang#122173 (Don't ICE in CTFE if raw/fn-ptr types differ) - rust-lang#122175 (Bless tidy issues order) - rust-lang#122179 (rustc: Fix typo) - rust-lang#122181 (Fix crash in internal late lint checking) - rust-lang#122183 (interpret: update comment about read_discriminant on uninhabited variants) Failed merges: - rust-lang#122076 (Tweak the way we protect in-place function arguments in interpreters) - rust-lang#122132 (Diagnostic renaming 3) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#121025 (add known-bug tests for derive failure to detect packed repr) - rust-lang#121194 (Refactor pre-getopts command line argument handling) - rust-lang#121563 (Use `ControlFlow` in visitors.) - rust-lang#122173 (Don't ICE in CTFE if raw/fn-ptr types differ) - rust-lang#122175 (Bless tidy issues order) - rust-lang#122179 (rustc: Fix typo) - rust-lang#122181 (Fix crash in internal late lint checking) - rust-lang#122183 (interpret: update comment about read_discriminant on uninhabited variants) Failed merges: - rust-lang#122076 (Tweak the way we protect in-place function arguments in interpreters) - rust-lang#122132 (Diagnostic renaming 3) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121025 - oli-obk:taint_after_errors, r=petrochenkov add known-bug tests for derive failure to detect packed repr We only taint if it was a normal item. Modules and imports are untouched. Tainting them needs to be done differently, and it's unclear if that would be useful or desirable. If we just taint them into `Res::Err`, we end up losing some duplicate name messages *in the presence of other resolution errors*. r? `@petrochenkov`
We only taint if it was a normal item. Modules and imports are untouched. Tainting them needs to be done differently, and it's unclear if that would be useful or desirable. If we just taint them into
Res::Err
, we end up losing some duplicate name messages in the presence of other resolution errors.r? @petrochenkov