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`.
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).
Along the way, two changes are made:
* The recently-added type parameters for `Ord` and `Eq` are
removed. These were mistakenly added while adding them to `PartialOrd`
and `PartialEq`, but they don't make sense given the laws that are
required for (and use cases for) `Ord` and `Eq`.
* More explicit laws are added for `PartialEq` and `PartialOrd`,
connecting them to their associated mathematical concepts.
In the future, many of the impls should be generalized; see
since generalizing later is not a breaking change.
[breaking-change]
