Fix ICE when documentation includes intra-doc-link
When collecting intra-doc-links we could trigger the loading of extra crates into the crate store due to name resolution finding crates referred to in documentation but not in code. This might be due to
configuration differences or simply referring to something else.
This would cause an ICE because the newly loaded crate metadata existed in a crate store associated with the rustdoc global context, but the resolver had its own crate store cloned just before the documentation processing began and as such it could try and look up crates in a store which lacked them.
In this PR, I add support for `--extern-private` to the `rustdoc` tool so that it is supported for `compiletest` to then pass the crates in; and then I fix the issue by forcing the resolver to look over all the crates before we then lower the input ready for processing into documentation.
The first commit (the `--extern-private`) could be replaced with a commit which adds support for `--extern` to `compiletest` if preferred, though I think that adding `--extern-private` to `rustdoc` is more useful anyway since it makes the CLI a little more like `rustc`'s which might help reduce surprise for someone running it by hand or in their own test code.
The PR is meant to fix#66159 though it may also fix#65840.
cc @GuillaumeGomez
This PR BREAKS CODE THAT WAS ACCEPTED ON STABLE. It's arguably a bug
that this was accepted in the first place, but here we are. See #62272
for more info.
These errors will be triggered before the MIR const-checker runs,
causing all other errors to be silenced. They are now checked in the
`const-{if,loop}` tests.
Add some tests for fixed ICEs
Closes#30904 (fixed between nightly-2019-07-14 and nightly-2019-07-31)
Closes#40231 (example 1 is fixed in 1.32.0, example 2 is fixed in 1.38.0)
Closes#52432 (fixed in rustc 1.40.0-beta.1 (76b40532a 2019-11-05))
Closes#63279 (fixed in rustc 1.40.0-nightly (246be7e1a 2019-10-25))
r? @Centril
Add a callback that allows compiler consumers to override queries.
This pull request adds an additional callback that allows compiler consumers such as Prusti and MIRAI to override queries. My hope is that in this way it will be possible to get access to the internal compiler information (e.g. borrow checker) without major changes to the compiler.
This pull request is work in progress because I am still testing if I can get the information which I need.
cc @nikomatsakis
r? @oli-obk
Fix MIR lowering evaluation order and soundness bug
* Fixes a soundness issue with built-in index operations
* Ensures correct evaluation order of assignment expressions where the RHS is a FRU or is a use of a local of reference type.
* Removes an unnecessary symbol to string conversion
closes#65909closes#65910
support issue = "none" in unstable attributes
This works towards fixing #41260.
This PR allows the use of `issue = "none"` in unstable attributes and makes changes to internally store the issue number as an `Option<NonZeroU32>`. For example:
```rust
#[unstable(feature = "unstable_test_feature", issue = "none")]
fn unstable_issue_none() {}
```
It was not made optional because feedback seen here #60860 suggested that people might forget the issue field if it was optional.
I could not remove the current uses of `issue = "0"` (of which there are a lot) because the stage 0 compiler expects the old syntax. Once this is available in the stage 0 compiler we can replace all uses of `"0"` with `"none"` and no longer allow `"0"`. This is my first time contributing, so I'm not sure what the protocol is with two-part things like this, so some guidance would be appreciated.
r? @varkor
Fix error message about exported symbols from proc-macro crates
Someone forgot to update the error message after `#[proc_macro]` and
`#[proc_macro_attribute]` were stabilized.
Refactor slice pattern usefulness checking
As a follow up to https://github.com/rust-lang/rust/pull/65874, this PR changes how variable-length slice patterns are handled in usefulness checking. The objectives are: cleaning up that code to make it easier to understand, and paving the way to handling fixed-length slices more cleverly too, for https://github.com/rust-lang/rust/issues/53820.
Before this, variable-length slice patterns were eagerly expanded into a union of fixed-length slices. Now they have their own special constructor, which allows expanding them a bit more lazily.
As a nice side-effect, this improves diagnostics.
This PR shows a slight performance improvement, mostly due to https://github.com/rust-lang/rust/pull/66129/commits/149792b6080f40875c0072aae378a0eb31d23df0. This will probably have to be reverted in some way when we implement or-patterns.
An expression like `x[1][{ x = y; 2}]` would perform the bounds check
for the inner index operation before evaluating the outer index. This
would allow out of bounds memory accesses.
Make error and warning annotations mandatory in UI tests
This change makes error and warning annotations mandatory in UI tests.
The only exception are tests that use error patterns to match compiler
output and don't have any annotations.
Fixes#55596.
This change makes error and warning annotations mandatory in UI tests.
The only exception are tests that use error patterns to match compiler
output and don't have any annotations.
Support registering inert attributes and attribute tools using crate-level attributes
And remove `#[feature(custom_attribute)]`.
(`rustc_plugin::Registry::register_attribute` is not removed yet, I'll do it in a follow up PR.)
```rust
#![register_attr(my_attr)]
#![register_tool(my_tool)]
#[my_attr] // OK
#[my_tool::anything] // OK
fn main() {}
```
---
Some tools (`rustfmt` and `clippy`) used in tool attributes are hardcoded in the compiler.
We need some way to introduce them without hardcoding as well.
This PR introduces a way to do it with a crate level attribute.
The previous attempt to introduce them through command line (https://github.com/rust-lang/rust/pull/57921) met some resistance.
This probably needs to go through an RFC before stabilization.
However, I'd prefer to land *this* PR without an RFC to able to remove `#[feature(custom_attribute)]` and `Registry::register_attribute` while also providing a replacement.
---
`register_attr` is a direct replacement for `#![feature(custom_attribute)]` (https://github.com/rust-lang/rust/issues/29642), except it doesn't rely on implicit fallback from unresolved attributes to custom attributes (which was always hacky and is the primary reason for the removal of `custom_attribute`) and requires registering the attribute explicitly.
It's not clear whether it should go through stabilization or not.
It's quite possible that all the uses should migrate to `#![register_tool]` (https://github.com/rust-lang/rust/issues/66079) instead.
---
Details:
- The naming is `register_attr`/`register_tool` rather than some `register_attributes` (plural, no abbreviation) for consistency with already existing attributes like `cfg_attr`, or `feature`, etc.
---
Previous attempt: https://github.com/rust-lang/rust/pull/57921
cc https://github.com/rust-lang/rust/issues/44690
Tracking issues: #66079 (`register_tool`), #66080 (`register_attr`)
Closes https://github.com/rust-lang/rust/issues/29642
Split libsyntax apart
In this PR the general idea is to separate the AST, parser, and friends by a more data / logic structure (tho not fully realized!) by separating out the parser and macro expansion code from libsyntax. Specifically have now three crates instead of one (libsyntax):
- libsyntax:
- concrete syntax tree (`syntax::ast`)
- definition of tokens and token-streams (`syntax::{token, tokenstream}`) -- used by `syntax::ast`
- visitors (`syntax::visit`, `syntax::mut_visit`)
- shared definitions between `libsyntax_expand`
- feature gating (`syntax::feature_gate`) -- we could possibly move this out to its own crater later.
- attribute and meta item utilities, including used-marking (`syntax::attr`)
- pretty printer (`syntax::print`) -- this should possibly be moved out later. For now I've reduced down the dependencies to a single essential one which could be broken via `ParseSess`. This entails that e.g. `Debug` impls for `Path` cannot reference the pretty printer.
- definition of `ParseSess` (`syntax::sess`) -- this is used by `syntax::{attr, print, feature_gate}` and is a common definition used by the parser and other things like librustc.
- the `syntax::source_map` -- this includes definitions used by `syntax::ast` and other things but could ostensibly be moved `syntax_pos` since that is more related to this module.
- a smattering of misc utilities not sufficiently important to itemize -- some of these could be moved to where they are used (often a single place) but I wanted to limit the scope of this PR.
- librustc_parse:
- parser (`rustc_parse::parser`) -- reading a file and such are defined in the crate root tho.
- lexer (`rustc_parse::lexer`)
- validation of meta grammar (post-expansion) in (`rustc_parse::validate_attr`)
- libsyntax_expand -- this defines the infra for macro expansion and conditional compilation but this is not libsyntax_ext; we might want to merge them later but currently libsyntax_expand is depended on by librustc_metadata which libsyntax_ext is not.
- conditional compilation (`syntax_expand::config`) -- moved from `syntax::config` to here
- the bulk of this crate is made up of the old `syntax::ext`
r? @estebank
rustc_metadata: don't let LLVM confuse rmeta blobs for COFF object files.
This has likely been a silent issue since 1.10 but only caused trouble recently (see https://github.com/rust-lang/rust/issues/65536#issuecomment-552018224), when recent changes to the `rmeta` schema introduced more opportunities for COFF parse errors.
To prevent any undesired interactions with old compilers, I've renamed the file inside `rlib`s from `rust.metadata.bin` to `lib.rmeta` (not strongly attached to it, suggestions welcome).
Fixes#65536.
<hr/>
Before:
```
$ llvm-objdump -all-headers build/*/stage1-std/*/release/deps/libcore-*.rmeta
build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libcore-6b9e8b5a59b79a1d.rmeta: file format COFF-<unknown arch>
architecture: unknown
start address: 0x00000000
Sections:
Idx Name Size VMA Type
SYMBOL TABLE:
```
After:
```
$ llvm-objdump -all-headers build/*/stage1-std/*/release/deps/libcore-*.rmeta
llvm-objdump: error: 'build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libcore-6b9e8b5a59b79a1d.rmeta':
The file was not recognized as a valid object file
```
[mir-opt] Handle return place in ConstProp and improve SimplifyLocals pass
Temporarily rebased on top of #66074. The top 2 commits are new.
r? @oli-obk
[mir-opt] Implement pass to remove branches on uninhabited variants
Based on discussion [here](https://github.com/rust-lang/rust/pull/64890#discussion_r333612125), this is a pass to eliminate dead code that is caused by branching on an enum with uninhabited variants.
r? @oli-obk
Rollup of 6 pull requests
Successful merges:
- #65949 (Move promotion into its own pass)
- #65994 (Point at where clauses where the associated item was restricted)
- #66050 (Fix C aggregate-passing ABI on powerpc)
- #66134 (Point at formatting descriptor string when it is invalid)
- #66172 (Stabilize @file command line arguments)
- #66226 (add link to unstable book for asm! macro)
Failed merges:
r? @ghost
Point at formatting descriptor string when it is invalid
When a formatting string contains an invalid descriptor, point at it
instead of the argument:
```
error: unknown format trait `foo`
--> $DIR/ifmt-bad-arg.rs:86:17
|
LL | println!("{:foo}", 1);
| ^^^
|
= note: the only appropriate formatting traits are:
- ``, which uses the `Display` trait
- `?`, which uses the `Debug` trait
- `e`, which uses the `LowerExp` trait
- `E`, which uses the `UpperExp` trait
- `o`, which uses the `Octal` trait
- `p`, which uses the `Pointer` trait
- `b`, which uses the `Binary` trait
- `x`, which uses the `LowerHex` trait
- `X`, which uses the `UpperHex` trait
```
