Triage digest: Wed Oct 14 2015


Nominated (I-nominated) issues

Method lookup goes down the auto-deref rabbit hole when it doesn't need to (#19509)

  • Added I-nominated. By @brson

Allow where clauses involving types which don't include a type parameter. (#27972)

Settle execution order uncertainty for `+=` (#28160)

#28669 caused regression compiling pinyin crate on nightly (#28853)

Nightly regression: lifetime error with autoderef (#28854)

Nightly regression around HRTBs, likely connected to wf changes (#28934)

  • Added I-nominated. By @aturon

Nightly regression in borrow checker (#28936)

  • Added I-nominated. By @alexcrichton

Nightly regression: Incorrect "parameter type may not live long enough" warning (#29048)

  • Added I-nominated. By @alexcrichton

    triage: I-nominated

Unsoundness in borrowck around deref and mutable refs (#29053)

  • Added I-nominated. By @sfackler

Beta-nominated issues

check upvars in closures that are in statics (#28131, closed)

Warn on `pub extern crate`. (#28486, closed)

Make function pointers implement traits for up to 12 parameters (#28560, closed)

use the infcx tables to check if a closure is Copy (#28626, closed)

Un-regress conflicting destructors (#28681, closed)

rustc: Don't lint about isize/usize in FFI (#28779, closed)

Reject "+" and "-" when parsing floats. (#29050, open)

  • Added beta-nomianted. By @alexcrichton

    triage: beta-nomianted

Remaining issues

`Arc` should only require `Sync`, not `Send` (#20257)

  • Removed I-nominated. By @alexcrichton

Correctly handle dllimport on Windows/MSVC (#27438)

  • Added P-low. By @nikomatsakis

    triage: P-low

    After discussion with @alexcrichton, my conclusion was that the remaining problems are low priority, with the exception of the issues discussed (and hopefully addressed) in RFC

    My understanding of the situation is roughly as follows (feel free to correct me if you feel I am mistaken):

    1. Windows generally requires that imports/exports from DLLs be specially declared.
    2. But Rust crates do not, typically, know whether they are being compiled for use in a DLL or not
    • rlibs can be used in either way
    • but static linking is the default
    1. Currently, we use some set of declarations that are incorrect but the Windows linker nonetheless patches them up. The semantics are correct in all cases but the “fixup” results in suboptimal performance under the following scenarios:
    • when using dynamic linking in Windows, function calls suffer from an extra level of indirection
    • when using static linking in Windows, accessing static variables requires an extra load
    1. The performance impact of the above measures in real-world applications has not been measured. @alexcrichton expects it is low, particularly as static linking is the default for Rust (where fn calls are fast), and static variables are unusual.
    2. If we wanted to improve the situation, language changes are unnecessary, though of course they might be one route. At worst, we could fix this problem by having rlibs not contain the full .o on Windows, but rather LLVM IR (or something similar). We could then patch up the declarations at the last minute, when we know how a crate is to be used. Another option might be having cargo propagate the information about whether a crate will be used for dynamic or static linking more aggressively.

Explicit OIBIT impls hide the default impls (#27554)

  • Added P-medium. By @nikomatsakis

    triage: P-medium

    We discussed this last week in the language subteam meeting. Our conclusion was that there is (potentially) an issue here where the desired semantics are not entirely clear. It is backwards incompatible to fix it but deemed low risk, because the bad scenario is when one is trying to “add to” the default set that obey a particular trait (or remove further from the negative set, I suppose).

    Some notes from our discussion:

    The intent of an impl like this is somewhat unclear. Why did one write the impl in the first place? Was the goal to cover a case that the default rules would have excluded? Or was it perhaps to narrow down the default rules to a smaller set of acceptable cases (which kind of “opts out” by “opting in”)? The latter is the current semantics; it does seem plausible that a naive read of the code might think that the impl was listing out the cases that are Sync, versus adding to an implicit set. A short-term fix we might use is to try and report errors if the impl is “unnecessary”. Overall though our conclusion was the current semantics ought to be revisited with specialization in mind, since there is a lot of overlap (no pun intended!) between the situation here and that of specialization.

Generic type defaults should not be allowed if they don’t satisfy type constraints (#28024)

  • Added I-nominated. By @nikomatsakis
  • Added P-medium. By @nikomatsakis

    I'm also going to lower the triage. It seems unlikely that anyone would *intentionally* abuse this, and I think we'll be able to fix this without undue anger or breakage out there in the wild.

    triage: P-medium

Audit iterator specializations for side effects (#28810)

  • Added P-medium. By @alexcrichton

    triage: P-medium

Permalink to this digest


closed #2

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.