Skip to content

Crates using placement syntax behind a cfg broken #50832

New issue
New issue
Closed
Closed
Crates using placement syntax behind a cfg broken#50832
Assignees
nikomatsakis
Labels
C-bugCategory: This is a bug.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
Milestone
1.27

Description

@emilyalbini
emilyalbini
opened on May 17, 2018

Some crates were using <- behind a feature flag, so they worked on stable even if the placement syntax was nightly-only. After removing it though they fail to compile even on stable with a syntax error, because <- is not recognized anymore.

Activity

  1. emilyalbini
    added
    I-nominated
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
    C-bugCategory: This is a bug.
    on May 17, 2018
  2. emilyalbini
    added this to the 1.27 milestone on May 17, 2018

  3. kennytm commented on May 17, 2018

    @kennytm
    kennytm
    on May 17, 2018
    Member

    It is already fixed in mbox 0.5.0 and 0.4.4.

  4. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    nikomatsakis
    on May 17, 2018
    Contributor

    Oh, that's annoying. We should patch rayon-hash.

  5. petrochenkov commented on May 17, 2018

    @petrochenkov
    petrochenkov
    on May 17, 2018
    Contributor

    This is not the first time this is happening, removal of impl Trait for .. {} caused same consequences (see #46480).
    We should probably continue parsing <- and report the error later in AST validation.

  6. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    nikomatsakis
    on May 17, 2018
    Contributor

    Discussed in the @rust-lang/compiler meeting. I think we reached this consensus:

    • in this case, yes, we should do as @petrochenkov suggests: keep parsing, error in AST validation
    • if in the future, if it happens that we want to repurpose the syntax, we deal with it then: best of course is to use an edition for it, but maybe by then there no longer exist crates using it
    • going forward, it would be ideal if we could do some kind of "pre-cfg / expansion" feature check to try and avoid this in the future; that may or may not be feasible though, and we couldn't do it retroactively for all existing things anyway

  7. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    nikomatsakis
    on May 17, 2018
    Contributor

    Some discussion of the final at or around here in the IRC logs

    https://botbot.me/mozilla/rustc/2018-05-17/?msg=100165163&page=3

  8. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    nikomatsakis
    on May 17, 2018
    Contributor

    triage: P-high

  9. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    nikomatsakis
    on May 17, 2018
    Contributor

    Would anyone have time to whip up a change to the parser?

    cc @rust-lang/compiler @aidanhs

  10. kennytm
    added
    P-highHigh priority
    on May 17, 2018
  11. nikomatsakis
    removed
    I-nominated
    on May 17, 2018

  12. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    nikomatsakis
    on May 17, 2018
    Contributor

    For reference, the PR that reverted the syntax was #48333

  13. cuviper commented on May 17, 2018

    @cuviper
    cuviper
    on May 17, 2018
    Member

    I am working on rayon-hash. The quick hack would be to just nuke the placement stuff, but I'm trying to do a proper update to catch up to std's code -- fun with git subtree.

    But frankly, I don't know of anyone really using rayon-hash anyway.

  14. cuviper commented on May 17, 2018

    @cuviper
    cuviper
    on May 17, 2018
    Member

    Fixed in rayon-hash 0.3.0.

  15. nikomatsakis
    self-assigned this
    on May 23, 2018

  16. nikomatsakis commented on May 23, 2018

    @nikomatsakis
    nikomatsakis
    on May 23, 2018
    Contributor

    I'll handle this.

  17. nikomatsakis commented on May 24, 2018

    @nikomatsakis
    nikomatsakis
    on May 24, 2018
    Contributor

    Restored in #51052

  18. leoyvens commented on May 24, 2018

    @leoyvens
    leoyvens
    on May 24, 2018
    Contributor

    We could try calling more attention to lib authors about this through the API guidelines.

  19. bors
    added a commit that references this issue on May 26, 2018

    Auto merge of #51052 - nikomatsakis:obsolete-arrow, r=petrochenkov

    1594c6c
  20. bors
    closed this as completedin #51052on May 26, 2018

  21. estebank commented on Sep 19, 2018

    @estebank
    estebank
    on Sep 19, 2018
    Contributor

    The two regressions where about <-, but we also reverted the in syntax as well, which has degraded back a couple of errors, like the following:

    fn main() {
    let i = ();
    for x in in 0..1 {}
    i;
}

    Would it be ok to create a PR removing the in parsing while keeping the current <- handling for a while longer?

    CC #36611 #52964 #51602

  22. emilyalbini
    added a commit that references this issue on Sep 22, 2018

    Rollup merge of rust-lang#54409 - estebank:remove-in, r=pnkfelix

    1eee532
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

C-bugCategory: This is a bug.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions