- 01 7月, 2018 8 次提交
-
-
由 Zack M. Davis 提交于
There are at least a couple (and plausibly even three) diagnostics that could use the spans of visibility modifiers in order to be reliably correct (rather than hacking and munging surrounding spans to try to infer where the visibility keyword must have been). We follow the naming convention established by the other `Spanned` HIR nodes: the "outer" type alias gets the "prime" node-type name, the "inner" enum gets the name suffixed with an underscore, and the variant names are prefixed with the prime name and `pub use` exported from here (from HIR). Thanks to veteran reviewer Vadim Petrochenkov for suggesting this uniform approach. (A previous draft, based on the reasoning that `Visibility::Inherited` should not have a span, tried to hack in a named `span` field on `Visibility::Restricted` and a positional field on `Public` and `Crate`. This was ... not so uniform.)
-
由 Zack M. Davis 提交于
Visibility spans were added to the AST in #47799 (d6bdf296) as a `Spanned<_>`—which means that we need to choose a span even in the case of inherited visibility (what you get when there's no `pub` &c. keyword at all). That initial implementation's choice is pretty counterintuitive, which could matter if we want to use it as a site to suggest inserting a visibility modifier, &c. (The phrase "Schelling span" in the comment is meant in analogy to the game-theoretic concept of a "Schelling point", a value that is chosen simply because it's what one can expect to agree upon with other agents in the absence of explicit coördination.)
-
由 bors 提交于
Update the miri submodule r? @kennytm
-
由 bors 提交于
Bootstrap from 1.28.0 beta
-
由 Mark Simulacrum 提交于
Previously Cargo would hardlink all the dependencies into the "root" as foo.dll and the `toplevel` array would get populated with these, but that's no longer the case. Instead, cargo will only do this for the final artifacts/final libraries. Rustbuild is updated to continue looping through the artifacts mentioned instead of early-returning. This should fix the bug. @alexcrichton found the cause of this and suggested this fix.
-
由 Mark Simulacrum 提交于
-
由 bors 提交于
optimize `places_conflict` to avoid complex vectors etc Fixes #51820
-
由 bors 提交于
Point to lifetime spans on lifetime errors
-
- 30 6月, 2018 16 次提交
-
-
由 Oliver Schneider 提交于
-
由 bors 提交于
Do not allow LLVM to increase a TLS's alignment on macOS. This addresses the various TLS segfault on macOS 10.10. Fix #51794. Fix #51758. Fix #50867. Fix #48866. Fix #46355. Fix #44056.
-
由 kennytm 提交于
-
由 bors 提交于
hygiene: Implement transparent marks and use them for call-site hygiene in proc-macros Fixes https://github.com/rust-lang/rust/issues/50050
-
由 bors 提交于
Lowering cleanups [1/N]
-
由 bors 提交于
Implement PartialEq between &str and OsString This fixes #49854. It allows equality comparison between `OsString` values and `str` references, such as `os_string == "something"`.
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
`$crate` is not resolved at def-site of a macro, but rather at "transitive def-site"
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
Fix incorrect type mismatch label pointing at return type CC #46302.
-
由 Esteban Küber 提交于
-
由 bors 提交于
Make the public API of the alloc crate a subset of std This only affects **unstable** APIs. I plan to submit an RFC proposing to stabilize the crate. The reason it isn’t stable yet (https://github.com/rust-lang/rust/issues/27783) is in case we end up merging the standard library crates into one. However the `core` crate is already stable, so if that happens we’ll need to keep it working somehow (likely by making replacing its contents by `pub use` items). We can do the same for `alloc`. This PR will hopefully make this easier, but even if that doesn’t happen consistency with `std` seems good.
-
- 29 6月, 2018 16 次提交
-
-
由 bors 提交于
Update LLVM to 1c817c7a0c828b8fc8e8e462afbe5db41c7052d1 https://github.com/rust-lang/llvm/pull/118 https://github.com/rust-lang/llvm/pull/119
-
由 bors 提交于
[NLL] Better move errors Make a number of changes to improve the quality of NLL cannot move errors. * Group errors that occur in the same `match` with the same cause. * Suggest `ref`, `&` or removing `*` to avoid the move. * Show the place being matched on. Differences from AST borrowck: * `&` is suggested over `ref` when matching on a place that can't be moved from. * Removing `*` is suggested instead of adding `&` when applicable. * Sub-pattern spans aren't used, this would probably need Spans on Places. Closes #45699 Closes #46627 Closes #51187 Closes #51189 r? @pnkfelix
-
由 Simon Sapin 提交于
-
由 Simon Sapin 提交于
-
由 Simon Sapin 提交于
… since `std` has no corresponding reexports. Use `alloc::vec::Vec` and `alloc::string::String` instead.
-
由 Simon Sapin 提交于
-
由 Simon Sapin 提交于
This matches std::collections
-
由 Simon Sapin 提交于
-
由 Simon Sapin 提交于
-
由 Gabriel Majeri 提交于
-
由 Gabriel Majeri 提交于
-
由 Gabriel Majeri 提交于
Allows for example `os_string == "something"`
-
由 bors 提交于
Add a fallback for stacktrace printing for older Windows versions. Some time ago we switched stack inspection functions of dbghelp.dll to their newer alternatives that also capture inlined context. Unfortunately, said new alternatives are not present in older dbghelp.dll versions. In particular Windows 7 at the time of writing has dbghelp.dll version 6.1.7601 from 2010, that lacks StackWalkEx and friends. Tested on my Windows 7 - both msvc and gnu versions produce a readable stacktrace. Fixes #50138
-
由 bors 提交于
park/park_timeout: prohibit spurious wakeups in next park <pre><code> // The implementation currently uses the trivial strategy of a Mutex+Condvar // with wakeup flag, which does not actually allow spurious wakeups. </pre></code> Because does not actually allow spurious wakeups. so we have let thread.inner.cvar.wait(m) in the loop to prohibit spurious wakeups. but if notified after we locked, this notification doesn't be consumed, it return, the next park will consume this notification...this is also 'spurious wakeup' case, 'one unpark() wakeups two park()'. We should improve this situation: `thread.inner.state.store(EMPTY, SeqCst);`
-
由 bors 提交于
Arc: remove unused allocation from Weak::new() It seems non-obvious that calling `Weak::new()` actually allocates space for the entire size of `T`, even though you can **never** access that data from such a constructed weak pointer. Besides that, if someone were to create many `Weak:new()`s, they could be unknowingly wasting a bunch of memory. This change makes it so that `Weak::new()` allocates no memory at all. Instead, it is created with a null pointer. The only things done with a `Weak` are trying to upgrade, cloning, and dropping, meaning there are very few places that the code actually needs to check if the pointer is null.
-