The loop to load all the known impls from external crates seems to have been used because `ty::populate_implementations_for_trait_if_necessary` wasn't doing its job, and solely relying on it resulted in loading only impls in the same crate as the trait.
Coherence for `librustc` was reduced from 18.310s to 0.610s, from stage1 to stage2.
Interestingly, type checking also went from 46.232s to 42.003s, though that could be noise or unrelated improvements.
On a smaller scale, `fn main() {}` now spends 0.003s in coherence instead of 0.368s, which fixes#22068.
It also peaks at only 1.2MB, instead of 16MB of heap usage.
Rustdoc fixes for associated items
This is related to isssue #22442 and solves it partly.
This solves the search index links of associated types and constants,
so that they link to the trait page.
Also add an Associated Constants section if constants are present.
There were still some mentions of `~[T]` and `~T`, mostly in comments and debugging statements. I tried to do my best to preserve meaning, but I might have gotten some wrong-- I'm happy to fix anything :)
I've found that there are still huge amounts of occurrences of `task`s in the documentation. This PR tries to eliminate all of them in favor of `thread`.
This syntax was removed in b24a3b8 but references remained in the
grammar, the reference, rustdoc generation, and some auxiliary test
files that don't seem to have been used since 812637e.
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
My change in #24797 had a bug, described in that issue’s comments, and first discovered in issue #24918. This fixes it.
I tested this new `main.js` by changing the `main.js` content of [a rendered docs page](https://doc.rust-lang.org/std/option/) to this new content. The ‘[−]’ button worked again.
I am also including another related fix, because it would require manual merging if I made a separate pull request for it. The page-global ‘[−]’ button currently adds `#` to the end of the URL whenever it is clicked. I am changing its `href` from `#` to `javascript:void(0)` (the same as the `href` for section-specific ‘[−]’ links) to fix that.
To separate concerns, instead of checking the state of `#toggle-all-docs` by looking at its label text, I add or remove a class `will-expand` depending on whether the button’s next click will expand everything. (The `if` statement’s two branches were swapped as part of this change.)
I moved the desired text values to a function `labelForToggleButton`, so changing the values will be easier. I also note in a comment the other file where the text is duplicated.
To allow the labels of both types of toggle buttons to be uniformly set, I added a `span.inner` to the global button too.
I split the template in `render.rs` into multiple lines to make room for the `span`, and that adds whitespace around the `[` and `]` text elements. That seems to be okay, though – the page still looks the same.
I updated the CSS styling for `.collapse-toggle > .inner` to add a little extra space around the symbol, to make minus signs easier to identify. (`#toggle-all-docs > .inner` does not need the same style, since its text size is bigger, so it naturally puts more space around the symbol.)
Error was noted at https://travis-ci.org/rust-lang/rust/builds/60643081#L371
I didn’t just put the content of the node on another line, because that would add spaces around the element content, messing up the JavaScript that checks what the content is.
So that when you click the link, the URL doesn’t get # appended to it.
The non-page-global docs toggle link, which is created in `main.js`, already uses this `href` value.
Closes#17841.
The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough.
There is still some significant functionality missing from this commit:
- ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~
- Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
- Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865.
- ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~
Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
The minus sign ‘−’ is the same width as the plus sign ‘+’, so the button’s transition between the two symbols will look slightly smoother.
If you don’t want to use literal Unicode characters, I can change ‘−’ to `\u2212`. I’m not starting with that suggestion because ‘−’ is easier to read and understand, and if I used `\u2212`, it would probably be necessary to also comment the usage on each line to explain what character is being used.
So that if people accidentally delete the character, they won’t re-type it as a hyphen, which would cause bugs.
I changed ‘+’ too, even though it won’t be re-typed incorrectly, so that it is easier to see when plus is used as a symbol for the button, and when it is used as an operator in code. It also makes it clearer that the use of an entity for minus is on purpose, so people won’t be tempted to replace the entity incorrectly with a hyphen character.
Changes the style guidelines regarding unit tests to recommend using a
sub-module named "tests" instead of "test" for unit tests as "test"
might clash with imports of libtest.
For now, words() is left in (but deprecated), and Words is a type alias for
struct SplitWhitespace.
Also cleaned up references to s.words() throughout codebase.
Closes#15628
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
This makes it illegal to have unconstrained lifetimes that appear in an associated type definition. Arguably, we should prohibit all unconstrained lifetimes -- but it would break various macros. It'd be good to evaluate how large a break change it would be. But this seems like the minimal change we need to do to establish soundness, so we should land it regardless. Another variant would be to prohibit all lifetimes that appear in any impl item, not just associated types. I don't think that's necessary for soundness -- associated types are different because they can be projected -- but it would feel a bit more consistent and "obviously" safe. I'll experiment with that in the meantime.
r? @aturon
Fixes#22077.
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
Whenever a type implements Deref, rustdoc will now add a section to the "methods
available" sections for "Methods from Deref<Target=Foo>", listing all the
inherent methods of the type `Foo`.
Closes#19190
This commit is an overhaul to how rustdoc deals with stability of the standard
library. The handling has all been revisited with respect to Rust's current
approach to stability in terms of implementation as well as the state of the
standard library today. The high level changes made were:
* Stable items now have no marker by default
* Color-based small stability markers have been removed
* Module listings now fade out unstable/deprecated items slightly
* Trait methods have a separate background color based on stability and also
list the reason that they are unstable.
* `impl` blocks with stability no longer render at all. This may be re-added
once the compiler recognizes stability on `impl` blocks.
* `impl` blocks no longer have stability of the methods implemente indicated
* The stability summary has been removed
Closes#15468Closes#21674Closes#24201
