rustdoc: overhaul code block lexing errors
Fixes#53919.
This PR moves the reporting of code block lexing errors from rendering time to an early pass, so we can use the compiler's error reporting mechanisms. This dramatically improves the diagnostics in this situation: we now de-emphasize the lexing errors as a note under a warning that has a span and suggestion instead of just emitting errors at the top level.
Additionally, this PR generalizes the markdown -> source span calculation function, which should allow other rustdoc warnings to use better spans in the future.
Last, the PR makes sure that the code block is always emitted in the docs, even if it fails to highlight correctly.
Of note:
- The new pass unfortunately adds another pass over the docs to gather the doc blocks for syntax-checking. I wonder if this could be combined with the pass that looks for testable blocks? I'm not familiar with that code, so I don't know how feasible that is.
- `pulldown_cmark` doesn't make it easy to find the spans of the code blocks, so the code that calculates the spans is a little nasty. It works for all the test cases I threw at it, but I wouldn't be surprised if an edge case would break it. Should have a thorough review.
- This PR worsens the state of #56885, since those certain fatal lexing errors are now emitted before docs get generated at all.
Usually the layout of any locals is required at least three times, once
when it becomes live, once when it is written to, and once it is read
from. By adding a cache for them, we can reduce the number of layout
queries speeding up code that is heavy on const_eval.
Use a faster early exit during region expansion
Turns out that the equality check for regions is rather expensive, and
the current early exit check works in such a way, that the comparison is
even done twice. As we only really care about the case of equal scopes,
we can perform a faster, more specialized check and move it up one
level, so we can eventually skip the additional full comparison as well.
[rustbuild] Rebuild std after changes to codegen backends
Use `clear_if_dirty` on std for backend changes, just as we do for
changes to rustc itself, so new codegen is correctly applied to all
later compiler stages.
Fixes#48298.
OSX: fix#57534 registering thread dtors while running thread dtors
r? @alexcrichton
- "fast" `thread_local` destructors get run even on the main thread
- "fast" `thread_local` dtors, can initialize other `thread_local`'s
One corner case where this fix doesn't work, is when a C++ `thread_local` triggers the initialization of a rust `thread_local`.
I did not add any std::thread specific flag to indicate that the thread is currently exiting, which would be checked before registering a new dtor (I didn't really know where to stick that). I think this does the trick tho!
Let me know if anything needs tweaking/fixing/etc.
resolves this for macos: https://github.com/rust-lang/rust/issues/28129
fixes: https://github.com/rust-lang/rust/issues/57534
Remove GCE cloud setting from AppVeyor config
AppVeyor has informed us that this may no longer be necessary after some
infrastructure upgrades on their side, so let's see how this goes!
Rollup of 4 pull requests
Successful merges:
- #57452 (Improve docs for Formatter)
- #57689 (Redo `hir::Stmt`)
- #57723 (Point at cause for expectation in return type type error)
- #57736 (Remove delay_span_bug from qualify_min_const_fn)
Failed merges:
r? @ghost
Redo `hir::Stmt`
A couple of changes that make things simpler and more consistent.
This should probably wait until after 1.32 lands to land, to avoid late breakage for tools.
Improve docs for Formatter
Some improvements to `std::fmt::Formatter` to make it a bit more consistent with other documentation, as well as calling out that you don't ever instantiate one yourself.
Update cargo
Unblocks #56884 cc @euclio
6 commits in 2b4a5f1f0bb6e13759e88ea9512527b0beba154f..ffe65875fd05018599ad07e7389e99050c7915be
2019-01-12 04:13:12 +0000 to 2019-01-17 23:57:50 +0000
- Better error message for bad manifest with `cargo install`. (rust-lang/cargo#6560)
- relax rustdoc output assertion (rust-lang/cargo#6559)
- touch some files when we use them (rust-lang/cargo#6477)
- Add documentation for new package/publish feature flags. (rust-lang/cargo#6553)
- Update chat link to Discord. (rust-lang/cargo#6554)
- Fix typo (rust-lang/cargo#6552)
r? @alexcrichton
add applicability to remaining suggestions
Fixes#50723.
I noticed that the suggestion methods on `DiagnosticBuilder` weren't actually deprecated due to #57679. This PR deprecates them properly and fixes the remaining usages.
There's also a PR for clippy at rust-lang/rust-clippy#3667.
Add missing unpretty option help message
There are some missing help messages that is printed `ructc -Zunpretty help` and receiving invalid option.
related with #16419, #45721, #21085, #31916
make trait-aliases work across crates
This is rebase of a small part of @alexreg's PR #55994. It focuses just on the changes that integrate trait aliases properly into crate metadata, excluding the stylistic edits and the trait objects.
The stylistic edits I also rebased and can open a separate PR.
The trait object stuff I found challenging and decided it basically needed to be reimplemented. For now I've excluded it.
Since this is really @alexreg's work (I really just rebased) I am going to make it r=me once it is working.
Fixes#56488.
Fixes#57023.
Simplify `TokenStream` some more
These commits simplify `TokenStream`, remove `ThinTokenStream`, and avoid some clones. The end result is simpler code and a slight perf win on some benchmarks.
r? @petrochenkov
Rollup of 10 pull requests
Successful merges:
- #57268 (Add a target option "merge-functions", and a corresponding -Z flag (works around #57356))
- #57476 (Move glob map use to query and get rid of CrateAnalysis)
- #57501 (High priority resolutions for associated variants)
- #57573 (Querify `entry_fn`)
- #57610 (Fix nested `?` matchers)
- #57634 (Remove an unused function argument)
- #57653 (Make the contribution doc reference the guide more)
- #57666 (Generalize `huge-enum.rs` test and expected stderr for more cross platform cases)
- #57698 (Fix typo bug in DepGraph::try_mark_green().)
- #57746 (Update README.md)
Failed merges:
r? @ghost
Generalize `huge-enum.rs` test and expected stderr for more cross platform cases
With this change, I am able to build and test cross-platform `rustc`
In particular, I can use the following in my `config.toml`:
```
[build]
host = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
```
Before this change, my attempt to run the test suite would fail
because the error output differs depending on what your host and
targets are.
----
To be concrete, here are the actual messages one can observe:
```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `std::option::Option<[u32; 35184372088831]>` is too big for the current architecture
error: aborting due to previous error
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `[u32; 35184372088831]` is too big for the current architecture
error: aborting due to previous error
```
To address these variations, I changed the test to be more aggressive
in its normalization strategy. We cannot (and IMO should not)
guarantee that `Option` will appear in the error output here. So I
normalized both types `Option<[u32; N]>` and `[u32; N]` to just `TYPE`
Remove an unused function argument
The only use was a debug printing, which might help someone with debugging dataflow problems, but seems otherwise useless
High priority resolutions for associated variants
In https://github.com/rust-lang/rust/pull/56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.
This PR changes the rules to give variants highest priority instead.
Some motivation:
- If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits.
- Inherent associated items have higher priority during resolution than associated items from traits.
- The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority.
- It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.
Crater found some regressions from this change, but they are all in type positions, e.g.
```rust
fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`?
```
, so variants are not usable there right now, but they may become usable in the future if https://github.com/rust-lang/rfcs/pull/2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.
Move glob map use to query and get rid of CrateAnalysis
~Also includes commits from ~https://github.com/rust-lang/rust/pull/57392~ and ~https://github.com/rust-lang/rust/pull/57436~.~
With glob map calculated unconditionally in https://github.com/rust-lang/rust/pull/57392, this PR moves the calculated glob map to `GlobalCtxt` and exposes a relevant query (as we do with other queries which copy precomputed data over from the `Resolver`).
This allows us to get rid of the `CrateAnalysis` struct in an attempt to simplify the compiler interface.
cc @Zoxc
r? @nikomatsakis @Zoxc @petrochenkov
Add a target option "merge-functions", and a corresponding -Z flag (works around #57356)
This commit adds a target option "merge-functions", which takes values in ("disabled", "trampolines", or "aliases" (default is "aliases")), to allow targets to opt out of the MergeFunctions LLVM pass. Additionally, the latest commit also adds an optional -Z flag, "merge-functions", which takes the same values and has precedence over the target option when both are specified.
This works around https://github.com/rust-lang/rust/issues/57356.
cc @eddyb @japaric @oli-obk @nox @nagisa
Also thanks to @denzp and @gnzlbg for discussing this on rust-cuda!
### Motivation
Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3 [1], and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler `ptxas`). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does.
### Related work
The current behavior of rustc is to enable MergeFunctions at -O2 and -O3 [1], and also to enable the use of function aliases within MergeFunctions [2] [3]. MergeFunctions seems to have some benefits, such as reducing code size and fixing a crash [4], which is why it is enabled. However, MergeFunctions both with and without function aliases is incompatible with the NVPTX target; a more detailed example for both cases is given below.
clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default.
### Examples/more details
Consider an example Rust lib using `extern "ptx-kernel"` functions: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore.rs. If we try to compile this with nightly rustc, we get the following compiler error:
LLVM ERROR: Module has aliases, which NVPTX does not support.
This error happens because: (1) functions `foo` and `bar` have the same body, so are candidates to be merged by MergeFunctions; and (2) rustc configures MergeFunctions to generate function aliases using the "mergefunc-use-aliases" LLVM option [2] [3], but the NVPTX backend does not support those aliases.
Okay, so we can try omitting "mergefunc-use-aliases", and then rustc will happily emit PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-mergefunc-nousealiases-bad.ptx. However, this PTX is invalid! When we try to assemble it with `ptxas` (I'm on the CUDA 9.2 toolchain), we get an assembler error:
ptxas nocore-mergefunc-nousealiases-bad.ptx, line 38; error : Illegal call target, device function expected
ptxas fatal : Ptx assembly aborted due to errors
What's happening is that MergeFunctions rewrites the `bar` function to call `foo`. However, directly calling an `extern "ptx-kernel"` function from another `extern "ptx-kernel"` is wrong.
If we disable the MergeFunctions pass from running at all, rustc generates correct PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-nomergefunc-ok.ptx
[1] a36b960df6/src/librustc_codegen_ssa/back/write.rs (L155)
[2] a36b960df6/src/librustc_codegen_llvm/llvm_util.rs (L64)
[3] https://github.com/rust-lang/rust/pull/56358
[4] https://github.com/rust-lang/rust/pull/49479
Fix stack overflow when finding blanket impls
Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.
To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.
Fixes#56701
I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
