| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This is a functionally equivalent, minimally invasive backport of #90044, which
fixes the problem that compiling any binary with the target
aarch64-unknown-linux-musl fails unless lld is used for linking (#89626).
I have tested this backport by building aarch64-unknown-linux-gnu, installing
the std libraries for the -musl and -gnu variants in
rustc-beta-aarch64-unknown-linux-gnu/rustc/lib/rustlib and running helloworld
successfully for both targets on arm64 hardware.
|
|
|
|
|
|
(cherry picked from commit a24e2eddb1f5b1fca76eb1a3a6079188f9d54fd7)
|
|
(cherry picked from commit 9db9811ddf96dab53f4cd5b4b406d34572259f3c)
|
|
(cherry picked from commit 4154e8acf045a13bf57bc9b3c487f838f17230c8)
|
|
(cherry picked from commit fc8113d04e5ea4ae5c053388b503eb7013006e26)
|
|
(cherry picked from commit 76bc02715e3495f66860e1d470d224d2607336a6)
|
|
(cherry picked from commit 9c84ac86d1325816c25531e95777adf467cf31e4)
|
|
The adjustments are used later by ExprUseVisitor to build Place projections
and without adjustments it can produce invalid result.
(cherry picked from commit f5560754591532d7cde4c9f5dd51dfbd7670e98f)
|
|
(cherry picked from commit d50a4753b8cffdb17e2d83282d95b61e266521fb)
|
|
(cherry picked from commit 6771ac3f19171ba9fa5b9c8d652d8fd7ad131444)
|
|
(cherry picked from commit c6b69017e21610b1ef491c028697728fbd3f581a)
|
|
(cherry picked from commit 4b970231fd1254580fbddabab74a125404fea0de)
|
|
(cherry picked from commit aff37f8f7b0a14493e17bc9fd7844f4392d08241)
|
|
See https://github.com/rust-lang/rust/issues/90024#issuecomment-950105433
(cherry picked from commit 9158fc2071d8b6424ca56bcebc1cf21d264e9d7d)
|
|
This lint is not yet ready for stable use, primarily due to false positives in edge
cases; we want to test it out more before stabilizing.
(cherry picked from commit 185fa5625656c5a5cb979397b131d1c8bbadeba9)
|
|
Address CVE-2021-42574.
|
|
This reverts commit 36a1076d24697621a3bb67ef654b4eb79647aa54, reversing
changes made to e1e9319d93aea755c444c8f8ff863b0936d7a4b6.
|
|
|
|
|
|
|
|
polymorphization: shims and predicates
Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on.
- #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in.
- #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization, so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced, but it doesn't hurt.
- #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675, this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped.
- Polymorphization now explicitly checks (and skips) foreign items, this is necessary for stage2 bootstrapping to work when polymorphization is enabled.
- The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously, some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate, not the local crate), adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir`, so it seemed more reasonable to not change the conditional.
- `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally, but not with an ICE, but it fails in a fresh checkout too, so 🤷♂️.
r? `@lcnr`
|
|
Correct small typo
|
|
clippy::complexity fixes
|
|
|
|
Remove trailing semicolon from macro call span
Macro call site spans are now less surprising/more consistent since they no longer contain a semicolon after the macro call.
The downside is that we need to do a little guesswork to get the semicolon in diagnostics. But this should not be noticeable since it is rare for the semicolon to not immediately follow the macro call.
|
|
|
|
Some outlives cleanup
No semantic changes here, only moving code around + using `LocalDefId` instead of `HirId`
r? ````@nikomatsakis````
|
|
Emit impl difference error for GenericBoundFailure too
Fixes #86787
r? ````@estebank````
|
|
r=oli-obk
emitter: current substitution can be multi-line
Fixes #89280.
In `splice_lines`, there is some arithmetic to compute the required alignment such that future substitutions in a suggestion are aligned correctly. However, this assumed that the current substitution's span was only on a single line. In circumstances where this was not true, it could result in a arithmetic overflow when the substitution's end column was less than the substitution's start column.
r? ````@oli-obk````
|
|
Remove alloc::prelude
As per the libs team decision in #58935.
Closes #58935
|
|
|
|
|
|
|
|
|
|
In `splice_lines`, there is some arithmetic to compute the required
alignment such that future substitutions in a suggestion are aligned
correctly. However, this assumed that the current substitution's span
was only on a single line. In circumstances where this was not true, it
could result in a arithmetic overflow when the substitution's end
column was less than the substitution's start column.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #86011 (move implicit `Sized` predicate to end of list)
- #89821 (Add a strange test for `unsafe_code` lint.)
- #89859 (add dedicated error variant for writing the discriminant of an uninhabited enum variant)
- #89870 (Suggest Box::pin when Pin::new is used instead)
- #89880 (Use non-checking TLS relocation in aarch64 asm! sym test.)
- #89885 (add long explanation for E0183)
- #89894 (Remove unused dependencies from rustc_const_eval)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove unused dependencies from rustc_const_eval
|
|
add long explanation for E0183
Addresses #61137
|
|
Suggest Box::pin when Pin::new is used instead
This fixes an incorrect diagnostic.
**Based on #89390**; only the last commit is specific to this PR. "Ignore whitespace changes" also helps here.
|
|
add dedicated error variant for writing the discriminant of an uninhabited enum variant
This is conceptually different from hitting an `Unreachable` terminator. Also add some sanity check making sure we don't write discriminants of things that do not have discriminants.
r? ``@oli-obk``
|
|
move implicit `Sized` predicate to end of list
In `Bounds::predicates()`, move the implicit `Sized` predicate to the
end of the generated list. This means that if there is an explicit
`Sized` bound, it will be checked first, and any resulting
diagnostics will have a more useful span.
Fixes #85998, at least partially. ~~Based on #85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter.
I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason.
I also ran into an instance of #84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.
``@estebank`` this seems likely to conflict (slightly?) with your work on #85947; how would you like to resolve that?
|
|
Revert enum discriminants
Reverts stabilization of arbitrary enum discriminants per https://github.com/rust-lang/rust/issues/88621#issuecomment-929482371.
Reopens #60553.
|
|
As per the libs team decision in #58935.
Closes #58935
|
|
|
