It was pointed out in review that the glob-exported
underscore-suffixed convention for `Spanned` HIR nodes is no longer
preferred: see February 2016's #31487 for AST's migration away from
this style towards properly namespaced NodeKind enums.
This concerns #51968.
April 2016's Issue #33174 called out the E0446 diagnostics as
confusing. While adding the name of the restricted type to the message
(548e681f) clarified matters somewhat, Esteban Küber pointed out that we
could stand to place a secondary span on the restricted type.
Here, we differentiate between crate-visible, truly private, and
otherwise restricted types, and place a secondary span specifically on
the visibility modifier of the restricted type's declaration (which we
can do now that HIR visibilities have spans!).
At long last, this resolves#33174.
If the item is `pub`, one imagines users being confused as to why it's
not reachable/exported; a code suggestion is beyond our local knowledge
here, but we can at least offer a prose hint. (Thanks to Vadim
Petrochenkov for shooting down the present author's original bad idea
for the note text.)
While we're here, use proper HELP expectations instead of ad hoc
comments to communicate (and now, enforce) the expected suggestions in
test/ui/lint/suggestions.rs.
This is probably quite a lot less likely to come up in practice than the
"inherited" (no visibility keyword) case, but now that we have
visibility spans in the HIR, we can do this, and it presumably doesn't
hurt to be exhaustive. (Who can say but that the attention to detail
just might knock someone's socks off, someday, somewhere?)
This is inspired by #47383.
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.)
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.)
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.
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.
Implement PartialEq between &str and OsString
This fixes#49854.
It allows equality comparison between `OsString` values and `str` references, such as `os_string == "something"`.
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.
[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#45699Closes#46627Closes#51187Closes#51189
r? @pnkfelix
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
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);`
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.
Explicitely disable WASM code generation for Emscripten
Emscripten changed the default behavior recently:
bd050e64bb/ChangeLog.markdown (v1381-05172018)
It now defaults to WebAssembly and requires an explicit flag to generate asm.js.
WASM=0 is also valid for older emcc and thus doesn't break it.
