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).
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>.
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.
Drop support for all cloudabi targets
`cloudabi` is a tier-3 target, and [it is no longer being maintained upstream][no].
This PR drops supports for cloudabi targets. Those targets are:
* aarch64-unknown-cloudabi
* armv7-unknown-cloudabi
* i686-unknown-cloudabi
* x86_64-unknown-cloudabi
Since this drops supports for a target, I'd like somebody to tag `relnotes` label to this PR.
Some other issues:
* The tidy exception for `cloudabi` crate is still remained because
* `parking_lot v0.9.0` and `parking_lot v0.10.2` depends on `cloudabi v0.0.3`.
* `parking_lot v0.11.0` depends on `cloudabi v0.1.0`.
[no]: https://github.com/NuxiNL/cloudabi#note-this-project-is-unmaintained
Because trait impls bypass the standard `clean` hierarchy they do not
participate in the `propagate_doc_cfg` pass, so instead we need to
pre-collect all possible `doc(cfg)` attributes that will apply to them
when cleaning.
Rollup of 10 pull requests
Successful merges:
- #76829 (stabilize const_int_pow)
- #79080 (MIR visitor: Don't treat debuginfo field access as a use of the struct)
- #79236 (const_generics: assert resolve hack causes an error)
- #79287 (Allow using generic trait methods in `const fn`)
- #79324 (Use Option::and_then instead of open-coding it)
- #79325 (Reduce boilerplate with the `?` operator)
- #79330 (Fix typo in comment)
- #79333 (doc typo)
- #79337 (Use Option::map instead of open coding it)
- #79343 (Add my (`@flip1995)` work mail to the mailmap)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Allow using generic trait methods in `const fn`
Next step for https://github.com/rust-lang/rust/issues/67792, this now also allows code like the following:
```rust
struct S;
impl const PartialEq for S {
fn eq(&self, _: &S) -> bool {
true
}
}
const fn equals_self<T: PartialEq>(t: &T) -> bool {
*t == *t
}
pub const EQ: bool = equals_self(&S);
```
This works by threading const-ness of trait predicates through trait selection, in particular through `ParamCandidate`, and exposing it in the resulting `ImplSource`.
Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds, candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate, to avoid ambiguities when both a const and a non-const bound is present.
Change slice::to_vec to not use extend_from_slice
I saw this [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/String.3A.3Afrom%28.26str%29.20wonky.20codegen/near/216164455), and didn't see any update from it, so I thought I'd try to fix it. This converts `to_vec` to no longer use `extend_from_slice`, but relies on knowing that the allocated capacity is the same size as the input.
[Godbolt new v1](https://rust.godbolt.org/z/1bcWKG)
[Godbolt new v2 w/ drop guard](https://rust.godbolt.org/z/5jn76K)
[Godbolt old version](https://rust.godbolt.org/z/e4ePav)
After some amount of iteration, there are now two specializations for `to_vec`, one for `Copy` types that use memcpy, and one for clone types which is the original from this PR.
This is then used inside of `impl<T: Clone> FromIterator<Iter::Slice<T>> for Vec<T>` which is essentially equivalent to `&[T] -> Vec<T>`, instead of previous specialization of the `extend` function. This is because extend has to reason more about existing capacity by calling `reserve` on an existing vec, and thus produces worse asm.
Downsides: This allocates the exact capacity, so I think if many items are added to this `Vec` after, it might need to allocate whereas extending may not. I also noticed the number of faults went up in the benchmarks, but not sure where from exactly.
Fixes#79242
If a `macro_rules!` recursively builds up a nested nonterminal
(passing it to a proc-macro at each step), we will end up repeatedly
pretty-printing/retokenizing the same nonterminals. Unfortunately, the
'probable equality' check we do has a non-trivial cost, which leads to a
blowup in compilation time.
As a workaround, we cache the result of the 'probable equality' check,
which eliminates the compilation time blowup for the linked issue. This
commit only touches a single file (other than adding tests), so it
should be easy to backport.
The proper solution is to remove the pretty-print/retokenize hack
entirely. However, this will almost certainly break a large number of
crates that were relying on hygiene bugs created by using the reparsed
`TokenStream`. As a result, we will definitely not want to backport
such a change.
Stabilize `IpAddr::is_ipv4` and `is_ipv6` as const
Insta-stabilize the methods `is_ipv4` and `is_ipv6` of `std::net::IpAddr` as const, in the same way as [PR#76198](https://github.com/rust-lang/rust/pull/76198).
Possible because of the recent stabilization of const control flow.
Part of #76225 and #76205.
Also stabilize constctlz for const ctlz_nonzero.
The public methods stabilized const by this commit are:
* `{i*,u*}::checked_pow`
* `{i*,u*}::saturating_pow`
* `{i*,u*}::wrapping_pow`
* `{i*,u*}::overflowing_pow`
* `{i*,u*}::pow`
* `u*::next_power_of_two`
* `u*::checked_next_power_of_two`
* `u*::wrapping_next_power_of_two` (the method itself is still unstable)
Insta-stabilize the methods `is_ipv4` and `is_ipv6` of `IpAddr`.
Possible because of the recent stabilization of const control flow.
Also adds a test for these methods in a const context.
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.
This also required adding a loop guard in case clone panics
Add specialization for copy
There is a better version for copy, so I've added specialization for that function
and hopefully that should speed it up even more.
Switch FromIter<slice::Iter> to use `to_vec`
Test different unrolling version for to_vec
Revert to impl
From benchmarking, it appears this version is faster
Add test for eval order for a+=b
Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.
I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.
Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.
Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
Split each iterator adapter and source into individual modules
This PR creates individual modules for each iterator adapter and iterator source.
This is done to enhance the readability of corresponding modules (`adapters/mod.rs` and `sources.rs`) which were hard to navigate and read because of lots of repeated lines (e.g.: `adapters/mod.rs` was 3k lines long). This is also in line with some adapters which already had their own modules (`Flatten`, `FlatMap`, `Chain`, `Zip`, `Fuse`).
This PR also makes `Take`s adapter fields private (I have no idea why they were `pub(super)` before).
r? ``@LukasKalbertodt``
Consolidate exhaustiveness-related tests
I hunted for tests that only exercised the match exhaustiveness algorithm and regrouped them. I also improved integer-range tests since I had found them lacking while hacking around.
The interest is mainly so that one can pass `--test-args patterns` and catch most relevant tests.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.
I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.
Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.
Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
Get rid of some doctree items
They can be derived directly from the `hir::Item`, there's no special logic.
- TypeDef
- OpaqueTy
- Constant
- Static
- TraitAlias
- Enum
- Union
- Struct
Part of #78082 (the easiest part, I'm still debugging some other changes).
r? `@GuillaumeGomez`
Fix links to extern types in rustdoc (fixes#78777)
r? `@jyn514`
Fixes#78777.
The initial fix we tried was:
```diff
diff --git a/src/librustdoc/passes/collect_intra_doc_links.rs b/src/librustdoc/passes/collect_intra_doc_links.rs
index 8be9482acff..c4b7086fdb1 100644
--- a/src/librustdoc/passes/collect_intra_doc_links.rs
+++ b/src/librustdoc/passes/collect_intra_doc_links.rs
`@@` -433,8 +433,9 `@@` impl<'a, 'tcx> LinkCollector<'a, 'tcx> {
Res::PrimTy(prim) => Some(
self.resolve_primitive_associated_item(prim, ns, module_id, item_name, item_str),
),
- Res::Def(DefKind::Struct | DefKind::Union | DefKind::Enum | DefKind::TyAlias, did) => {
+ Res::Def(kind, did) if kind.ns() == Some(Namespace::TypeNS) => {
debug!("looking for associated item named {} for item {:?}", item_name, did);
+
// Checks if item_name belongs to `impl SomeItem`
let assoc_item = cx
.tcx
```
However, this caused traits to be matched, resulting in a panic when `resolve_associated_trait_item` is called further down in this function.
This PR also adds an error message for that panic. Currently it will look something like:
```rust
thread 'rustc' panicked at 'Not a type: DefIndex(8624)', compiler/rustc_metadata/src/rmeta/decoder.rs:951:32
```
I wasn't sure how to get a better debug output than `DefIndex(...)`, and am open to suggestions.
lint: Do not provide suggestions for non standard characters
Fixes#77273
Only provide suggestions if the case-fixed result is different than the original.
rustc_expand: Mark inner `#![test]` attributes as soft-unstable
Custom inner attributes are feature gated (https://github.com/rust-lang/rust/issues/54726) except for attributes having name `test` literally, which are not gated for historical reasons.
`#![test]` is an inner proc macro attribute, so it has all the issues described in https://github.com/rust-lang/rust/issues/54726 too.
This PR gates it with the `soft_unstable` lint.
