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

tuple structs with all-public fields can not be instantiated if one of the fields has an external attribute #66555

Closed
DarkKirb opened this issue Nov 19, 2019 · 6 comments · Fixed by #66669
Assignees
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-visibility Area: Visibility / privacy C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@DarkKirb
Copy link

In current nightly (2019-11-18 and also 2019-11-16) and stable (1.39.0), tuple structs can not be instantiated from an outside module directly if

  • all of the members are public
  • at least one of the struct members has an attribute (like #[serde(rename = "some_name")])

Example code that is broken:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=7108f99f96b03247b7d44bdf47091a1a

In the same module the code works:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a896f6f28a050228c4e91d9e3bcc5557

Same with normal structs:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=2083f2cae68b7378652bd239bb122d20

The broken code works in 1.38.0:

https://godbolt.org/z/_8KX6P

Meta

One of the affected installations:

rustc 1.41.0-nightly (5c5b8afd8 2019-11-16)
binary: rustc
commit-hash: 5c5b8afd80e6fa1d24632153cb2257c686041d41
commit-date: 2019-11-16
host: x86_64-apple-darwin
release: 1.41.0-nightly
LLVM version: 9.0
@jonas-schievink jonas-schievink added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-visibility Area: Visibility / privacy C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 19, 2019
@Erk-
Copy link
Contributor

Erk- commented Nov 19, 2019

It seems to only happen with external attributes. Attributes like #[deprecated] and similar does not show this bug.

@DarkKirb DarkKirb changed the title tuple structs with all-public fields can not be instantiated if one of the fields has an attribute tuple structs with all-public fields can not be instantiated if one of the fields has an external attribute Nov 19, 2019
@petrochenkov
Copy link
Contributor

Minimized:

mod m {
    pub struct S(#[rustfmt::skip] pub u8);
}

fn main() {
    m::S(0);
}

@petrochenkov
Copy link
Contributor

Similarly to #66487, this issue was introduced by #63468 and recently unmasked for derive helper attributes by #64694.

@petrochenkov petrochenkov self-assigned this Nov 20, 2019
@pnkfelix
Copy link
Member

Based on @petrochenkov 's assertion that this was introduced by PR #63468, marking this as a stable-to-stable regression.

@pnkfelix pnkfelix added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. P-high High priority labels Nov 21, 2019
@pnkfelix
Copy link
Member

pnkfelix commented Nov 22, 2019

Marking P-high, mostly because of the risk that a crate might rely on being able to use struct literal expressions in other modules, and then a later version of that crate wants to put an attribute on of the fields of the struct literal.

@petrochenkov
Copy link
Contributor

Fixed in #66669.

@bors bors closed this as completed in 4eee955 Nov 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-visibility Area: Visibility / privacy C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. 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.

5 participants