| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
|
|
|
|
Fix #19915
|
|
|
|
Build `clean::ConstantItem` values in the `inline` module and
pretty-print the AST for inlined const items.
Doc strings are still missing from inlined constants (see #19773).
Partially address #18156, #19722, #19185
Fix #15821
r? @alexcrichton
|
|
integrating into rustdoc etc.
|
|
|
|
Build `clean::ConstantItem` values in the `inline` module and
pretty-print the AST for inlined const items.
Doc strings are still missing from inlined constants (see #19773).
Partially address #18156, #19722, #19185
Fix #15821
|
|
|
|
Both `trait Foo for Sized?` and `<Sized? T>` are handled correctly.
Fix #18515
|
|
|
|
Both `trait Foo for Sized?` and `<Sized? T>` are handled correctly.
Fix #18515
|
|
|
|
|
|
|
|
completely.
|
|
|
|
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
|
|
|
|
|
|
Fix #16518
|
|
Fixes that unit-like structs cannot be used if they are reexported and
used in another crate. The compiler fails with an ICE, because unit-like
structs are exported as DefFn and the expression `UnitStruct` is
interpreted as function pointer instead of a call to the constructor.
To resolve this ambiguity tuple-like struct constructors are now exported
as CtorFn. When `rustc::metadata::decoder` finds a CtorFn it sets a new
flag `is_ctor` in DefFn to true.
Relevant changes are in `rustc::metadata::{encoder, decoder}` and in
`rustc::middle::ty`.
Closes #12660 and #16973.
|
|
The implementation essentially desugars during type collection and AST
type conversion time into the parameter scheme we have now. Only fully
qualified names--e.g. `<T as Foo>::Bar`--are supported.
|
|
This is done by adding a new field to the `DefTy` variant of `middle::def::Def`,
which also clarifies an error message in the process.
Closes #16712.
|
|
|
|
|
|
|
|
Per API meeting
https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md
# Changes to `core::option`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
However, a few methods have been deprecated, either due to lack of use or redundancy:
* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator` impl.
# Changes to `core::result`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
* `collect`: this functionality is being moved to a new `FromIterator` impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants.
Due to deprecations, this is a:
[breaking-change]
|
|
|
|
|
|
As of 8876ce44, `is_sugared_doc` is encoded in metadata, so there is no
need to assume that doc attributes came from sugared comments.
|
|
methods.
This paves the way to associated items by introducing an extra level of
abstraction ("impl-or-trait item") between traits/implementations and
methods. This new abstraction is encoded in the metadata and used
throughout the compiler where appropriate.
There are no functional changes; this is purely a refactoring.
|
|
Some minor changes to the compiler to expose this information. Very
inconvenient since struct fields aren't an item. Adds (yet another) table to
metadata.
Closes #15739
|
|
These were all just previously skipped.
Closes #15648
|
|
Previously a `pub use` would not rename the destination in rustdoc, it would
always use the destination ident instead of the renamed ident.
|
|
I'm not entirely sure if the correct space can be inferred when cleaning
Generics, so the impl has been switched to take the space explicitly.
Closes #15099
|
|
Closes #14585
|
|
[breaking-change]
|
|
This commit hooks rustdoc into the stability index infrastructure in two
ways:
1. It looks up stability levels via the index, rather than by manual
attributes.
2. It adds stability level information throughout rustdoc output, rather
than just at the top header. In particular, a stability color (with
mouseover text) appears next to essentially every item that appears
in rustdoc's HTML output.
Along the way, the stability index code has been lightly refactored.
|
|
Both of these items are surfaced as a DefTy, so some extra logic was needed in
the decoder module to figure out whether one is actually an enum or whether it's
a typedef.
Closes #14757
|
|
|
|
|
|
|
|
|
|
|
|
Previously, documentation for an inlined trait (i.e. a trait imported
and reexported from another crate) didn't display the trait's
supertraits.
Closes #14636
|
|
Apparently relying on provided_source in ty::Method is unreliable!
Closes #14594
|
|
If the type associated with the impl is `pub use`'d or referenced twice in a
downstream crate, the impl will attempt to be inlined twice.
Closes #14584
|
|
Closes #14583
|
|
These don't actually point to anything, so there's no need to inline them.
|
