- 26 8月, 2015 4 次提交
-
-
由 Ms2ger 提交于
There is no longer a need for that pattern, since enums are now qualified.
-
由 bors 提交于
See #19466 for background. r? @steveklabnik
-
由 Matt Brubeck 提交于
-
由 bors 提交于
According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms679351(v=vs.85).aspx: > If the function succeeds, the return value is the number of TCHARs stored in the output buffer, > excluding the terminating null character. _**Completely untested**_… since I have no Windows machine or anything of a sort to test this on. r? @aturon
-
- 25 8月, 2015 36 次提交
-
-
由 Simonas Kazlauskas 提交于
According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms679351(v=vs.85).aspx: > If the function succeeds, the return value is the number of TCHARs stored in the output buffer, > excluding the terminating null character.
-
由 bors 提交于
- Successful merges: #27905, #27968, #27978, #27982, #27988 - Failed merges:
-
由 Steve Klabnik 提交于
Fixes #27946
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
-
由 bors 提交于
Reserving lower_bound bytes was just silly. It’d be perfectly reasonable to have empty strings in the iterator, which could cause superfluous reallocation of the string, or to have more than one byte per string, which could cause additional reallocation (in practice it’ll balance out). The added complexity of this logic is simply pointless, adding a little bloat with no demonstrable advantage and slight disadvantage.
-
由 bors 提交于
-
由 bors 提交于
Fixes #27952
-
由 bors 提交于
On Linux the flag is just ignored if it is not supported: https://lwn.net/Articles/588444/ Still needs the values of O_CLOEXEC on the BSDs. Touches #24237.
-
由 Adam Crume 提交于
-
由 Adam Crume 提交于
-
由 bors 提交于
Part of #22709. cc @Veedrac r? @bluss I don't have added tests yet, I'll see how to do it tomorrow.
-
由 bors 提交于
- All the libstd tests are passing in the optimized build against a Zenfone2 and the x86 Android emulator. I haven't tested the other libraries though.
-
由 bors 提交于
Some hoedown FFI changes: - `HOEDOWN_EXT_NO_INTRA_EMPHASIS` constant changed. - Updated/tidied up all callback function signatures. - All opaque data access has an additional layer of indirection for some reason (`hoedown_renderer_data`). This also fixes #27862.
-
由 Simonas Kazlauskas 提交于
Fixes #27946
-
由 bors 提交于
This increases regionck performance greatly - type-checking on librustc decreased from 9.1s to 8.1s. Because of Amdahl's law, total performance is improved only by about 1.5% (LLVM wizards, this is your opportunity to shine!). before: 576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k after: 566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k I am somewhat worried really need to find out why we have this Red Queen's Race going on here. Originally I suspected it may be a problem from RFC1214's warnings, but it seems to be an effect from other changes. However, the increase seems to be mostly in LLVM's time, so I guess it's the LLVM wizards' problem. r? @nikomatsakis
-
由 Chris Morgan 提交于
Reserving lower_bound bytes was just silly. It’d be perfectly reasonable to have empty strings in the iterator, which could cause superfluous reallocation of the string, or to have more than one byte per string, which could cause additional reallocation (in practice it’ll balance out). The added complexity of this logic is simply pointless, adding a little bloat with no demonstrable advantage and slight disadvantage.
-
由 Björn Steinbrink 提交于
StructGEP seems clearer and probably does an even better job of the micro-optimization that we have in GEPi.
-
由 Björn Steinbrink 提交于
-
由 Björn Steinbrink 提交于
The functions is useful for all kinds of fat pointers, but get_len() just feels so wrong for trait object fat pointers. Let's use get_meta() because that's rather neutral.
-
由 Corey Farwell 提交于
-
由 Guillaume Gomez 提交于
-
由 Ariel Ben-Yehuda 提交于
-
由 bors 提交于
closes #19102
-
由 Ariel Ben-Yehuda 提交于
-
由 Eljay 提交于
-
由 Matěj Grabovský 提交于
-
由 Tobias Bucher 提交于
On Linux the flag is just ignored if it is not supported: https://lwn.net/Articles/588444/ Touches #24237.
-
由 Ariel Ben-Yehuda 提交于
-
由 Ariel Ben-Yehuda 提交于
this makes the code cleaner
-
由 Ariel Ben-Yehuda 提交于
This increases regionck performance greatly - type-checking on librustc decreased from 9.1s to 8.1s. Because of Amdahl's law, total performance is improved only by about 1.5% (LLVM wizards, this is your opportunity to shine!). before: 576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k after: 566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k I am somewhat worried really need to find out why we have this Red Queen's Race going on here. Originally I suspected it may be a problem from RFC1214's warnings, but it seems to be an effect from other changes. However, the increase seems to be mostly in LLVM's time, so I guess it's the LLVM wizards' problem.
-
由 Ariel Ben-Yehuda 提交于
This reduces the size of CodeExtent to 12 bytes (was 24). We should have a warning for this kind of problem.
-
由 Ariel Ben-Yehuda 提交于
this should reduce the size of ty::Region to 24 bytes (from 32), and they are treated differently in most cases anyway.
-
由 bors 提交于
Closes #27973
-