triage: I-nominated
triage: beta-nomianted
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): 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 3. 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 4. 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. 5. 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.
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.
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
triage: P-medium