Rollup of 14 pull requests
Successful merges:
- #49525 (Use sort_by_cached_key where appropriate)
- #49575 (Stabilize `Option::filter`.)
- #49614 (in which the non-shorthand patterns lint keeps its own counsel in macros)
- #49665 (Small nits to make couple of tests pass on mips targets.)
- #49781 (add regression test for #16223 (NLL): use of collaterally moved value)
- #49795 (Properly look for uninhabitedness of variants in niche-filling check)
- #49809 (Stop emitting color codes on TERM=dumb)
- #49856 (Do not uppercase-lint #[no_mangle] statics)
- #49863 (fixed typo)
- #49857 (Fix "fp" target feature for AArch64)
- #49849 (Add --enable-debug flag to musl CI build script)
- #49734 (proc_macro: Generalize `FromIterator` impl)
- #49730 (Fix ICE with impl Trait)
- #48270 (Replace `structurally_resolved_type` in casts check.)
Failed merges:
Replace `structurally_resolved_type` in casts check.
The behaviour of `resolve_type_vars_if_possible` is simpler and infallible. Other minor refactorings.
I'm not sure if this is backwards compatible, in theory resolving obligations between two cast checks could solve a dependency between them, but I don't know if that's actually possible and it doesn't sound like something we'd want to support.
Do not uppercase-lint #[no_mangle] statics
The reasoning being that `#[no_mangle]` expresses enough intention that there's likely a good reason for the name.
Fixes#36258.
Blindly checkpoint status of NLL mode ui tests
This takes the next (and potentially final?) step with #48879.
Namely, this PR got things to the point where I can successfully run `compiletest` on `src/test/ui` with `--compile-mode=nll`.
Here are the main pieces of it:
1. To figure out how to even run `compiletest` normally on the ui directory, I ran `x.py test -vv`, and then looked for the `compiletest` invocation that mentioned `src/test/ui`.
2. I took the aforementioned `compiletest` invocation and used it, adding `--compile-mode=nll` to the end. It had 170 failing cases.
3. Due to #49855, I had to edit some of the tests so that they fail even under NLL, via `#[rustc_error]`. That's the first commit. (Then goto 2 to double-check no such tests remain.)
4. I took the generated `build/target/test/foo.stderr` file for every case that failed, and blindly copied it to `src/test/foo.nll.stderr`. That's the second commit.
5. Goto 2 until there were no failing cases.
6. Remove any stamp files, and re-run `x.py test` to make sure that the edits and new `.nll.stderr` files haven't broken the pre-existing test suite.
add regression test for #16223 (NLL): use of collaterally moved value
Adds regression test for https://github.com/rust-lang/rust/issues/16223 which NLL fixes.
The current downside of this test is that it uses the `#![feature(box_patterns)]` and I haven't come up with a proper test that only uses the `#![feature(nll)]` - however, I don't know if this is even possible to test without `#![feature(box_syntax)]` or `#![feature(box_patterns)]`.
in which the non-shorthand patterns lint keeps its own counsel in macros
In issue #49588, Michael Lamparski pointed out a scenario in which the
non-shorthand-field-patterns lint could be triggered by a macro-expanded
pattern, in a way which was direly unwieldy for the macro author to guard
against and unreasonable to expect the macro user to take into account. We can
avoid this by not linting patterns that come from macro-expansions. Although
this entails accepting "false negatives" where the lint could genuinely improve
macro-templated code, avoiding the reported "true-but-super-annoying positive"
may be worth the trade? (Some precedent for these relative priorities exists as
no. 47775 (5985b0b0).)
Resolves#49588.
NOTE: I was careful to make each change in a manner that preserves the
existing diagnostic output (usually by ensuring that no lines were
added or removed). This means that the resulting source files are not
as nice to read as they were at the start. But we will have to review
these cases by hand anyway as follow-up work, so cleanup could
reasonably happen then (or not at all).
This commit adds even more pessimization to use the cached `TokenStream` inside
of an AST node. As a reminder the `proc_macro` API requires taking an arbitrary
AST node and transforming it back into a `TokenStream` to hand off to a
procedural macro. Such functionality isn't actually implemented in rustc today,
so the way `proc_macro` works today is that it stringifies an AST node and then
reparses for a list of tokens.
This strategy unfortunately loses all span information, so we try to avoid it
whenever possible. Implemented in #43230 some AST nodes have a `TokenStream`
cache representing the tokens they were originally parsed from. This
`TokenStream` cache, however, has turned out to not always reflect the current
state of the item when it's being tokenized. For example `#[cfg]` processing or
macro expansion could modify the state of an item. Consequently we've seen a
number of bugs (#48644 and #49846) related to using this stale cache.
This commit tweaks the usage of the cached `TokenStream` to compare it to our
lossy stringification of the token stream. If the tokens that make up the cache
and the stringified token stream are the same then we return the cached version
(which has correct span information). If they differ, however, then we will
return the stringified version as the cache has been invalidated and we just
haven't figured that out.
Closes#48644Closes#49846
Modify compile-fail/E0389 error message WIP
This fixes#47388
cc @nikomatsakis @estebank
r? @nikomatsakis
Certain ui tests were failing locally. I'll check if the same happens here too.
chalkify: Implement lowering rule Implied-Bound-From-Trait
For #49177.
TODO:
- [x] Implement where clauses besides trait and projection predicates
- [x] Is the output of the `lower_trait_higher_rank` test correct?
- [ ] Remove `Self::Trait` from the query `tcx.predicates_of(<trait_id>).predicates`
- [ ] Consider moving tests to compile-fail to make them more manageable
In issue #49588, Michael Lamparski pointed out a scenario in which the
non-shorthand-field-patterns lint could be triggered by a macro-expanded
pattern, in a way which was direly unwieldy for the macro author to guard
against and unreasonable to expect the macro user to take into account. We can
avoid this by not linting patterns that come from macro-expansions. Although
this entails accepting "false negatives" where the lint could genuinely improve
macro-templated code, avoiding the reported "true-but-super-annoying positive"
may be worth the trade? (Some precedent for these relative priorities exists as
no. 47775 (5985b0b0).)
Resolves#49588.
Impressing confused Python users with magical diagnostics is perhaps
worth this not-grossly-unreasonable (only 40ish lines) extra complexity
in the parser?
Thanks to Vadim Petrochenkov for guidance.
This resolves#46836.
[incremental] Hash `Allocation`s
`HashSet::insert` returns `true` if the value did not exist, which is the timing we want to hash the `Allocation`.
Fixes#49595
cc @oli-obk
mem-categorization, coherence fix
make mem-categorization use adjusted type for patterns: Fixes#49631
do not propagate `Err` when determing causal info: Fixes#48728
r? @eddyb
Fix regression in defaults #49344Fixes#49344 by not checking the well-formedness wrt defaults of predicates that contain lifetimes, which is consistent with not checking generic predicates.
r? @nikomatsakis
two-phase borrows: support multiple activations in one statement
The need for this has arisen since the introduction of two-phase borrows on
method autorefs in #49348. r'ing @pnkfelix to keep things off Niko's plate so he can make this redundant, and @pnkfelix is familiar with the code.
Fixes#49635Fixes#49662
r? @pnkfelix
Fix another circular deps link args issue
It turns out that the support in #49316 wasn't enough to handle all cases
notably the example in #48661. The underlying bug was connected to panic=abort
where lang items were listed in the `missing_lang_items` sets but didn't
actually exist anywhere.
This caused the linker backend to deduce that start-group/end-group wasn't
needed because not all items were defined. Instead the missing lang items that
don't actually need to have a definition are filtered out and not considered for
the start-group/end-group arguments
Closes#48661
Allow for re-using monomorphizations in upstream crates.
Followup to #48611. This implementation is pretty much finished modulo failing tests if there are any. Not quite ready for review yet though.
### DESCRIPTION
This PR introduces a `share-generics` mode for RLIBs and Rust dylibs. When a crate is compiled in this mode, two things will happen:
- before instantiating a monomorphization in the current crate, the compiler will look for that monomorphization in all upstream crates and link to it, if possible.
- monomorphizations are not internalized during partitioning. Instead they are added to the list of symbols exported from the crate.
This results in less code being translated and LLVMed. However, there are also downsides:
- it will impede optimization somewhat, since fewer functions can be internalized, and
- Rust dylibs will have bigger symbol tables since they'll also export monomorphizations.
Consequently, this PR only enables the `shared-generics` mode for opt-levels `No`, `Less`, `Size`, and `MinSize`, and for when incremental compilation is activated. `-O2` and `-O3` will still generate generic functions per-crate.
Another thing to note is that this has a somewhat similar effect as MIR-only RLIBs, in that monomorphizations are shared, but it is less effective because it cannot share monomorphizations between sibling crates:
```
A <--- defines `fn foo<T>() { .. }`
/ \
/ \
B C <--- both call `foo<u32>()`
\ /
\ /
D <--- calls `foo<u32>()` too
```
With `share-generics`, both `B` and `C` have to instantiate `foo<u32>` and only `D` can re-use it (from either `B` or `C`). With MIR-only RLIBs, `B` and `C` would not instantiate anything, and in `D` we would then only instantiate `foo<u32>` once.
On the other hand, when there are many leaf crates in the graph (e.g. when compiling many individual test binaries) then the `share-generics` approach will often be more effective.
### TODO
- [x] Add codegen test that makes sure monomorphizations can be internalized in non-Rust binaries.
- [x] Add codegen-units test that makes sure we share generics.
- [x] Add run-make test that makes sure we don't export any monomorphizations from non-Rust binaries.
- [x] Review for reproducible-builds implications.
