As discovered in #20376, the MSYS shell will silently rewrite arguemnts that
look like unix paths into their windows path counterparts for compatibility, but
the recently added `:kind` syntax added to the `-L` flag does not allow for this
form of rewriting. This means that the syntax can be difficult to use at an MSYS
prompt, as well as causing tests to fail when run manuall right now.
This commit takes the other option presented in the original issue to prefix the
path with `kind=` instead of suffixing it with `:kind`. For consistence, the
`-l` flag is also now migrating to `kind=name`.
This is a breaking change due to the *removal* of behavior with `-L`. All code
using `:kind` should now pass `kind=` for `-L` arguments. This is not currently,
but will become, a breaking change for `-l` flags. The old `name:kind` syntax is
still accepted, but all code should update to `kind=name`.
[breaking-change]
Closes#20376
This commit performs a second pass over the `std::thread_local` module. Most of
the functionality remains explicitly unstable, but the specific actions taken
were:
* `thread_local` is now stable
* `thread_local!` is now stable
* `thread_local::Key` is now stable
* `thread_local::Key::with` is now stable
* `thread_local::Key::destroyed` is deprecated in favor of a more general
`state` function
* `thread_local::Key::state` was added to query the three states that a key can
be in: uninitialized, valid, or destroyed. This function, and the
corresponding `State` enum, are both marked unstable as we may wish to expand
it later on.
* `thread_local::scoped` is entirely unstable. There hasn't been a whole lot of
usage of this module in the standard distribution, so it remains unstable at
this time.
Note that while the structure `Key` is marked stable, it is currently forced to
expose all of its implementation details due to the use of
construction-via-macro. The use of construction-via-macro is currently required
in order to place the `#[thread_local]` attribute on static in a
platform-specific manner. These stability attributes were assigned assuming that
it will be acceptable to tweak the implementation of `Key` in the future.
is still probably wrong since it fails to incorporate the ambiguity
resolution measures that `select` uses. Also, made more complicated by
the fact that trait object types do not impl their own traits yet.
Patch for #20340. `rustdoc --version` panics because it uses `rustc_driver::version`, which in turn checks the `verbose` flag, which was not defined for rustdoc. In this patch I have added a verbose flag to rustdoc, because I think it should be useful for other things besides --version.
Another possible fix would be to check if a verbose option was defined in `rustc_driver` or add an extra `version` function for rustdoc.
This patch resolves the second problem mentioned in #15877: function calls to integers, e.g. `3.b()`.
It does so, by checking whether the character following the first dot of a FLOAT_LIT is a character or an underscore (these should denote a valid identifier). This does not look like a particularly, but it seems like a lookahead of 1 is needed for this distinction.
Another interesting aspect are ranges that start with a integer constant, but end with a function call, e.g. `1..b()`. Rust treats this as a range from 1 to `b()`, but given that `1.` is a valid FLOAT_LIT, `1..b()` could be a function call to a float as well.
cc @cmr
Closes#19949 and rust-lang/rfcs#428
[breaking change]
If you have traits used with objects with static methods, you'll need to move
the static methods to a different trait.
r? @cmr
Adds a new 'beta cycle' variable that can be appended to the '-beta' version label, e.g. '-beta1'. Changes the version label for the beta channel temporarily to 'alpha'. Changes the artifact name of the beta channel to contain the version number instead of just being called 'beta'. The beta cycle number is currently set to 1.
The impact of this is that the first alphas will be called '1.0.0-alpha1' and the artifacts will also be called '1.0.0-alpha1-*.tar.gz'. We could alternately leave out the cycle number if we are confident there will be only one alpha cycle.
r? @alexcrichton cc @nikomatsakis @huonw
This patch marks `PartialEq`, `Eq`, `PartialOrd`, and `Ord` as
`#[stable]`, as well as the majorify of manual implementaitons of these
traits. The traits match the [reform RFC](https://github.com/rust-lang/rfcs/pull/439).
In the future, many of the impls should be generalized; see #20063.
However, there is no problem stabilizing the less general impls, since
generalizing later is not a breaking change.
r? @alexcrichton
The new semantics of this function are that the callbacks are run when the *main
thread* exits, not when all threads have exited. This implies that other threads
may still be running when the `at_exit` callbacks are invoked and users need to
be prepared for this situation.
Users in the standard library have been audited in accordance to these new rules
as well.
Closes#20012
This pull request adds the `rust-gdb` shell script which starts GDB with Rust pretty printers enabled. The PR also makes `rustc` add a special `.debug_gdb_scripts` ELF section on Linux which tells GDB that the produced binary should use the Rust pretty printers.
Note that at the moment this script will only work and be installed on Linux. On Mac OS X there's `rust-lldb` which works much better there. On Windows I had too many problems making this stable. I'll give it another try soonish.
You can use this script just like you would use GDB from the command line. It will use the pretty printers from the Rust "installation" found first in PATH. E.g. if you have `~/rust/x86_64-linux-gnu/stage1/bin` in your path, it will use the pretty printer scripts in `~/rust/x86_64-linux-gnu/stage1/lib/rustlib/etc`.
