Rollup of 6 pull requests
Successful merges:
- #97320 (Stabilize const_ptr_read)
- #110770 (Limit lifetime of format_args!() with inlined args.)
- #111021 (Move some tests)
- #111215 (Various changes to name resolution of anon consts)
- #111242 (support set `rpath` option for each target independently)
- #111282 (Remove some `assume`s from slice iterators that don't do anything)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove some `assume`s from slice iterators that don't do anything
Because the start pointer is iterators is already a `NonNull`, we emit the appropriate `!nonnull` metadata when loading the pointer to tell LLVM that it's non-null.
Probably the best way to see that it's the metadata that's important (and not the `assume`) is to observe that LLVM actually *removes* the `assume` from the optimized IR: <https://rust.godbolt.org/z/KhE6G963n>.
(I also checked that, yes, the if-not-ZST `assume` on `end` is still doing something: it's how there's a `!nonnull` metadata on its load, even though it's an ordinary raw pointer. The codegen test added in this PR fails if the other `assume` is removed.)
support set `rpath` option for each target independently
Currently the `rpath` option is a global config and it's effect on all targets.
But sometimes when developers edit the rustc code and try to release rust toolchains themselves, they may not want to add `rpath` in all targets to avoid dynamically linked shared object library privilege escalation attack.
This PR supports set `rpath` option for each target independently .
Common developers are not aware of the existence of this configuration option and do not affect the existing development process. This configuration option takes effect only after developers explicitly sets .
r? ``@albertlarsan68``
Various changes to name resolution of anon consts
Sorry this PR is kind of all over the place ^^'
Fixes#111012
- Rewrites anon const nameres to all go through `fn resolve_anon_const` explicitly instead of `visit_anon_const` to ensure that we do not accidentally resolve anon consts as if they are allowed to use generics when they aren't. Also means that we dont have bits of code for resolving anon consts that will get out of sync (i.e. legacy const generics and resolving path consts that were parsed as type arguments)
- Renames two of the `LifetimeRibKind`, `AnonConst -> ConcreteAnonConst` and `ConstGeneric -> ConstParamTy`
- Noticed while doing this that under `generic_const_exprs` all lifetimes currently get resolved to errors without any error being emitted which was causing a bunch of tests to pass without their bugs having been fixed, incidentally fixed that in this PR and marked those tests as `// known-bug:`. I'm fine to break those since `generic_const_exprs` is a very unstable incomplete feature and this PR _does_ make generic_const_exprs "less broken" as a whole, also I can't be assed to figure out what the underlying causes of all of them are. This PR reopens#77357#83993
- Changed `generics_of` to stop providing generics and predicates to enum variant discriminant anon consts since those are not allowed to use generic parameters
- Updated the error for non 'static lifetime in const arguments and the error for non 'static lifetime in const param tys to use `derive(Diagnostic)`
I have a vague idea why const-arg-in-const-arg.rs, in-closure.rs and simple.rs have started failing which is unfortunate since these were deliberately made to work, I think lifetime resolution being broken just means this regressed at some point and nobody noticed because the tests were not testing anything :( I'm fine breaking these too for the same reason as the tests for #77357#83993. I couldn't get `// known-bug` to work for these ICEs and just kept getting different stderr between CI and local `--bless` so I just removed them and will create an issue to track re-adding (and fixing) the bugs if this PR lands.
r? `@cjgillot` cc `@compiler-errors`
Revert "Populate effective visibilities in `rustc_privacy`"
This reverts commit cff85f22f5030fbe7266d272da74a9e76160523c, cc #110907. It needs to be fixed, but there are too many issues being reported that I wanted to put up a revert until a proper fix can be committed.
Fixes a ton of issues where private but still reachable impls were missing during codegen:
Fixes#111320Fixes#111321Fixes#111334Fixes#111357Fixes#111368Fixes#111373Fixes#111377Fixes#111386Fixes#111387
`@bors` p=1
r? `@petrochenkov`
This trait ref is derived from the self type and then equated to the
trait ref from the obligation.
For example, for `fn(): Fn(u32)`, `self_ty_trait_ref` is `Fn()`, which
is then equated to `Fn(u32)` (which will fail, causing the obligation to
fail).
`SelectionError` used to be 80 bytes (on 64 bit). That's quite big.
Especially because the selection cache contained `Result<_,
SelectionError>. The Ok type is only 32 bytes, so the 80 bytes
significantly inflate the size of the cache.
Most variants of the `SelectionError` seem to be hard errors, only
`Unimplemented` shows up in practice (for cranelift-codegen, it occupies
23.4% of all cache entries). We can just box away the biggest variant,
`OutputTypeParameterMismatch`, to get the size down to 16 bytes, well
within the size of the Ok type inside the cache.
Update books
## rust-lang/edition-guide
1 commits in 6038be9d37d7251c966b486154af621d1794d7af..f63e578b92ff43e8cc38fcaa257b660f45c8a8c2
2023-04-26 18:40:19 UTC to 2023-04-26 18:40:19 UTC
- Fix grammar (rust-lang/edition-guide#281)
## rust-embedded/book
2 commits in 897fcf566f16bf87bf37199bdddec1801fd00532..d9eb4c3f75435b008881062ffa77bf0d1527b37d
2023-05-08 10:06:29 UTC to 2023-05-08 07:19:03 UTC
- Update Interoperability section (rust-embedded/book#351)
- Update c-with-rust.md (rust-embedded/book#352)
## rust-lang/reference
3 commits in 1f8dc727e94ae4ef92adf70df979521a1ea1143e..28dc0f3576b55f5e57c5d6e65cd68ba3161e9fd5
2023-05-06 20:25:36 UTC to 2023-05-05 01:51:00 UTC
- Add an entry for macro_rules in the "Weak keywords" lexer block (rust-lang/reference#1356)
- Document f16c target feature (rust-lang/reference#1337)
- Fix example for non-x86 targets (rust-lang/reference#1334)
## rust-lang/rust-by-example
4 commits in 31961fe22521a779070a44a8f30a2b00a20b6212..8ee9528b72b927cff8fd32346db8bbd1198816f0
2023-05-01 21:18:34 UTC to 2023-04-25 11:19:41 UTC
- add: zero padding example (rust-lang/rust-by-example#1706)
- Update reenter_question_mark.md (rust-lang/rust-by-example#1705)
- Clarify array out-of-bounds behavior. (rust-lang/rust-by-example#1703)
- Update README.md (rust-lang/rust-by-example#1704)
## rust-lang/rustc-dev-guide
2 commits in 2a5eb92197e9cf8fe91164dcbf4f9b88c0d7e73d..28dbeaf5c44bc7f5111ad412e99f2d7c5cec6c90
2023-05-02 02:20:21 UTC to 2023-04-26 19:09:10 UTC
- Add unset-exec-env compiletest header. (rust-lang/rustc-dev-guide#1682)
- extend the sixth trait system requirement (rust-lang/rustc-dev-guide#1671)
Min specialization improvements
- Don't allow specialization impls with no items, such implementations are probably not correct and only occur as mistakes in the compiler and standard library
- Fix a missing normalization call
- Adds spans for lifetime errors from overly general specializations
Closes#79457Closes#109815
Implement builtin # syntax and use it for offset_of!(...)
Add `builtin #` syntax to the parser, as well as a generic infrastructure to support both item and expression position builtin syntaxes. The PR also uses this infrastructure for the implementation of the `offset_of!` macro, added by #106934.
cc `@petrochenkov` `@DrMeepster`
cc #110680 `builtin #` tracking issue
cc #106655 `offset_of!` tracking issue
tweak "make mut" spans when assigning to locals
Work towards fixing #106857
This PR just cleans up a lot of spans which is helpful before properly fixing the issues. Best reviewed commit-by-commit.
r? `@estebank`
