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 https://github.com/rust-lang/rfcs/pull/1296.
My understanding of the situation is roughly as follows (feel free to correct me if you feel I am mistaken):
- Windows generally requires that imports/exports from DLLs be specially declared.
- 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
- 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
- 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.
- 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
.oon 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