Skip to content
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

Regression in 1.26 with misplaced attributes #49934

Closed
pietroalbini opened this issue Apr 13, 2018 · 10 comments · Fixed by #50092
Closed

Regression in 1.26 with misplaced attributes #49934

pietroalbini opened this issue Apr 13, 2018 · 10 comments · Fixed by #50092
Labels
C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Milestone

Comments

@pietroalbini
Copy link
Member

All the regressed crates have a misplaced #[derive] in the codebase (such as a #[derive(Debug)] above a variable declaration). In Rust 1.25 the compiler accepts the code, but in Rust 1.26 it throws an error and then crashes.

Even if we keep the error (which could be turned into a warn-by-default lint) the ICE should be fixed.

@pietroalbini pietroalbini added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ I-nominated T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. regression-from-stable-to-beta Performance or correctness regression from stable to beta. C-bug Category: This is a bug. labels Apr 13, 2018
@pietroalbini pietroalbini added this to the 1.26 milestone Apr 13, 2018
@pietroalbini
Copy link
Member Author

pietroalbini commented Apr 13, 2018

This also happens with misplaced attributes on functions:

@pietroalbini pietroalbini changed the title Regression in 1.26 with misplaced derives Regression in 1.26 with misplaced attributes Apr 13, 2018
@Mark-Simulacrum
Copy link
Member

cc @alexcrichton @dtolnay -- proc-macro related changes presumably

@mgattozzi
Copy link
Contributor

I have a feeling I know where it's broken in one of my macros for chiisai based off the build log. I slapped an #[inline(always)] above a closure that gets passed to it in that macro. I'll need to confirm though. It's a non proc_macro just the regular macro_rules!

markschl added a commit to markschl/seq_io that referenced this issue Apr 16, 2018
@alexcrichton
Copy link
Member

My guess is that this isn't related to procedural macros but rather #49291, cc @tejom and @petrochenkov

@tejom
Copy link
Contributor

tejom commented Apr 16, 2018

The change that effected inline and closures was brought up in issue #49632

I don't mind making a change to make the original pull request a warning if that is preferred?

@tejom
Copy link
Contributor

tejom commented Apr 16, 2018

The ice with the derive check doesn't seem to be caused by #49291

fn main() {
        #[derive(Debug)]
        let _a = 5;

        #[repr(always)]
        let _x = 12;
}

This compiles with stable.
That pull request I made was in nightly on 2018-04-01, and that only has an error for the incorrect repr above _x
With nightly from 2018-04-10 The compiler crashed after showing an error about the incorrect derive.

@pietroalbini
Copy link
Member Author

pietroalbini commented Apr 17, 2018

Did a bisect run, and #49124 is the source of the ICE. cc @petrochenkov @abonander

@abonander
Copy link
Contributor

abonander commented Apr 17, 2018

I saw this issue earlier and meant to comment that I was pretty sure it was my PR, so I could have saved you a bisect. However, I haven't been able to build Rust for at least a week so I'd be mostly relying on Travis to test any fixes.

@abonander
Copy link
Contributor

Ironically I'm able to work on beta and not nightly.

However, compile-fail seems to eat the ICE because while I can reproduce it on master, I have to manually call the built rustc to get it because the compile-fail suite passes because it still produces the expected error.

@nikomatsakis
Copy link
Contributor

triage: P-high

Has a pending fix.

@nikomatsakis nikomatsakis added P-high High priority and removed I-nominated labels Apr 26, 2018
abonander added a commit to abonander/rust that referenced this issue Apr 29, 2018
This fixes the regression in rust-lang#49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly.

closes rust-lang#49934
bors added a commit that referenced this issue Apr 30, 2018
Warn on pointless #[derive] in more places

This fixes the regression in #49934 and ensures that unused `#[derive]` invocations on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. There is a separate warning hardcoded for `#[derive]` on macro invocations since linting (even the early-lint pass) occurs after expansion. This also adds regression tests for some nodes that were already warning properly.

closes #49934
pietroalbini pushed a commit to pietroalbini/rust that referenced this issue Apr 30, 2018
This fixes the regression in rust-lang#49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly.

closes rust-lang#49934
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants