* `rustc` should now compile under LLVM 9 or 10
* Compiler generates an error if `-Z instrument-coverage` is specified
but LLVM version is less than 11
* Coverage tests that require `-Z instrument-coverage` and run codegen
should be skipped if LLVM version is less than 11
- Only run for `QPath::Resolved` with `Some` self parameter (`<X as Y>::T`)
- Fall back to the previous behavior if the path can't be resolved
- Show what the behavior is if the type can't be normalized
- Run `resolve_vars_if_possible`
It's not clear whether or not this is necessary. See
https://github.com/rust-lang/rust/pull/77616 for more context.
- Add a test for cross-crate re-exports
- Use the same code for both `hir::Ty` and `Ty`
Update cargo
10 commits in 2af662e22177a839763ac8fb70d245a680b15214..bfca1cd22bf514d5f2b6c1089b0ded0ba7dfaa6e
2020-11-12 19:04:56 +0000 to 2020-11-24 16:33:21 +0000
- Shrink the progress bar, to give more space after it. (rust-lang/cargo#8892)
- Add some comments to the toml code (rust-lang/cargo#8887)
- Start searching git config at new path (rust-lang/cargo#8886)
- Fix documentation for CARGO_PRIMARY_PACKAGE. (rust-lang/cargo#8891)
- Bump to 0.51.0, update changelog (rust-lang/cargo#8894)
- Publish target's "doc" setting when emitting metadata (rust-lang/cargo#8869)
- Relaxes expectation of `cargo test` tests to accept test execution time (rust-lang/cargo#8884)
- Finish implementation of `-Zextra-link-arg`. (rust-lang/cargo#8441)
- Reproducible crate builds (rust-lang/cargo#8864)
- Allow resolver="1" to explicitly use the old resolver behavior. (rust-lang/cargo#8857)
Get rid of doctree::{ExternalCrate, ForeignItem, Trait, Function}
Closes#79314, closes#79331, closes#79332. Follow-up to #79264 and #79312, continues breaking up #78082.
r? `@GuillaumeGomez`
Rollup of 10 pull requests
Successful merges:
- #76858 (Add exploit mitigations chapter to the rustc book)
- #79310 (Make `fold_item_recur` non-nullable)
- #79312 (Get rid of `doctree::Impl`)
- #79321 (Accept '!' in intra-doc links)
- #79346 (Allow using `-Z fewer-names=no` to retain value names)
- #79351 (Fix typo in `keyword` docs for traits)
- #79354 (BTreeMap: cut out the ceremony around BoxedNode)
- #79358 (BTreeMap/BTreeSet: make public doc more consistent)
- #79367 (Allow disabling TrapUnreachable via -Ztrap-unreachable=no)
- #79374 (Add note to use nightly when using expr in const generics)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add note to use nightly when using expr in const generics
As recommended by `@Icnr` in #73899 and in zulip, I've added a note saying that const expressions can be used in nightly.
```
error: generic parameters may not be used in const operations
--> $DIR/issue-61935.rs:10:23
|
6 | Self:FooImpl<{N==0}>
| ^ cannot perform const operation using `N`
|
= help: const parameters may only be used as standalone arguments, i.e. `N`
= note: use feature(const_generics) and feature(const_evaluatable_checked) to enable this
error: aborting due to previous error
```
I hope the note is well written 😅
Allow disabling TrapUnreachable via -Ztrap-unreachable=no
Currently this is only possible by defining a custom target, which is quite unwieldy.
This is useful for embedded targets where small code size is desired. For example, on my project (thumbv7em-none-eabi) this yields a 0.6% code size reduction: 132892 bytes -> 132122 bytes (770 bytes down).
Fix typo in `keyword` docs for traits
This PR fixes a small typo in the `keyword_docs.rs` file, describing the differences between the 2015 and 2018 editions of traits.
Allow using `-Z fewer-names=no` to retain value names
Change `-Z fewer-names` into an optional boolean flag and allow using it
to either discard value names when true or retain them when false,
regardless of other settings.
Make `fold_item_recur` non-nullable
This gets rid of a bunch of `unwrap()`s and makes it a little more clear
what's going on.
Originally I wanted to make `fold_item` non-nullable too, which would
have been a lot nicer to work with, but unfortunately `stripper` does
actually return `None` in some places. I might make a follow-up moving
stripper to be special and not a pass so that passes can be
non-nullable.
Found while working on https://github.com/rust-lang/rust/issues/76998.
Add exploit mitigations chapter to the rustc book
This section documents the exploit mitigations applicable to the Rust compiler when building programs for the Linux operating system on the AMD64 architecture and equivalent. This was done for a project I'm currently working on, and I hope it'll also be helpful to others.
Currently you can get a list of lints and lint groups by running `rustc
-Whelp`. This prints an additional line at the end:
```
Compiler plugins can provide additional lints and lint groups. To see a
listing of these, re-run `rustc -W help` with a crate filename.
```
Clippy is such a "compiler plugin", that provides additional lints.
Running `clippy-driver -Whelp` (`rustc` wrapper) still only prints the
rustc lints with the above message at the end. But when running
`clippy-driver -Whelp main.rs`, where `main.rs` is any rust file, it
also prints Clippy lints. I don't think this is a good approach from a
UX perspective: Why is a random file necessary to print a help message?
This commit changes this behavior: Whenever a compiler callback
registers lints, it is assumed that these lints come from a plugin and
are printed without having to specify a Rust source file.
resolve: Do not put macros into `module.unexpanded_invocations` unless necessary
Macro invocations in modules <sup>(*)</sup> need to be tracked because they can produce named items when expanded.
We cannot give definite answer to queries like "does this module declare name `n`?" until all macro calls in that module are expanded.
Previously we marked too many macros as potentially producing named items.
E.g. in this example
```rust
mod m {
const C: u32 = line!();
}
```
`line!()` cannot emit any items into module `m`, but it was still marked.
This PR fixes that and marks macro calls as "unexpanded in module" only if they can actually emit named items into that module.
Diagnostics in UI test outputs have different order now because this change affects macro expansion order.
<sup>*</sup> Any containers for named items are called modules in resolve (that includes blocks, traits and enums in addition to `mod` items).
This section documents the exploit mitigations applicable to the Rust
compiler when building programs for the Linux operating system on the
AMD64 architecture and equivalent.
This is useful for embedded targets where small code size is desired.
For example, on my project (thumbv7em-none-eabi) this yields a 0.6% code size reduction.
Changes the coverage map injected into binaries compiled with
`-Zinstrument-coverage` to LLVM Coverage Mapping Format, Version 4 (from
Version 3). Note, binaries compiled with this version will require LLVM
tools from at least LLVM Version 11.
They were originally called "opt-in, built-in traits" (OIBITs), but
people realized that the name was too confusing and a mouthful, and so
they were renamed to just "auto traits". The feature flag's name wasn't
updated, though, so that's what this PR does.
There are some other spots in the compiler that still refer to OIBITs,
but I don't think changing those now is worth it since they are internal
and not particularly relevant to this PR.
Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
They were originally called "opt-in, built-in traits" (OIBITs), but
people realized that the name was too confusing and a mouthful, and so
they were renamed to just "auto traits". The feature flag's name wasn't
updated, though, so that's what this PR does.
There are some other spots in the compiler that still refer to OIBITs,
but I don't think changing those now is worth it since they are internal
and not particularly relevant to this PR.
Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
Qualify `panic!` as `core::panic!` in non-built-in `core` macros
Fixes#78333.
-----
Otherwise code like this
#![no_implicit_prelude]
fn main() {
::std::todo!();
::std::unimplemented!();
}
will fail to compile, which is unfortunate and presumably unintended.
This changes many invocations of `panic!` in a `macro_rules!` definition
to invocations of `$crate::panic!`, which makes the invocations hygienic.
Note that this does not make the built-in macro `assert!` hygienic.
Otherwise code like this
#![no_implicit_prelude]
fn main() {
::std::todo!();
::std::unimplemented!();
}
will fail to compile, which is unfortunate and presumably unintended.
This changes many invocations of `panic!` in a `macro_rules!` definition
to invocations of `$crate::panic!`, which makes the invocations hygienic.
Note that this does not make the built-in macro `assert!` hygienic.
