It's conditioned on `only-x86_64` because it doesn't reliably fail on
other platforms, it's optimization dependent and failed to ICE post-PGO
in
<https://github.com/rust-lang/rust/pull/132300#issuecomment-2443279042>.
Remove this test for now without prejudice against relanding the test in
a more reliable form.
Lint against getting pointers from immediately dropped temporaries
Fixes#123613
## Changes:
1. New lint: `dangling_pointers_from_temporaries`. Is a generalization of `temporary_cstring_as_ptr` for more types and more ways to get a temporary.
2. `temporary_cstring_as_ptr` is removed and marked as renamed to `dangling_pointers_from_temporaries`.
3. `clippy::temporary_cstring_as_ptr` is marked as renamed to `dangling_pointers_from_temporaries`.
4. Fixed a false positive[^fp] for when the pointer is not actually dangling because of lifetime extension for function/method call arguments.
5. `core::cell::Cell` is now `rustc_diagnostic_item = "Cell"`
## Questions:
- [ ] Instead of manually checking for a list of known methods and diagnostic items, maybe add some sort of annotation to those methods in library and check for the presence of that annotation? https://github.com/rust-lang/rust/pull/128985#issuecomment-2318714312
## Known limitations:
### False negatives[^fn]:
See the comments in `compiler/rustc_lint/src/dangling.rs`
1. Method calls that are not checked for:
- `temporary_unsafe_cell.get()`
- `temporary_sync_unsafe_cell.get()`
2. Ways to get a temporary that are not recognized:
- `owning_temporary.field`
- `owning_temporary[index]`
3. No checks for ref-to-ptr conversions:
- `&raw [mut] temporary`
- `&temporary as *(const|mut) _`
- `ptr::from_ref(&temporary)` and friends
[^fn]: lint **should** be emitted, but **is not**
[^fp]: lint **should not** be emitted, but **is**
cg_llvm: Use a type-safe helper to cast `&str` and `&[u8]` to `*const c_char`
In `rustc_codegen_llvm` there are many uses of `.as_ptr().cast()` to convert a string or byte-slice to `*const c_char`, which then gets passed through FFI.
This works, but is fragile, because there's nothing constraining the pointer cast to actually be from `u8` to `c_char`. If the original value changes to something else that has an `as_ptr` method, or the context changes to expect something other than `c_char`, the cast will silently do the wrong thing.
By making the cast more explicit via a helper method, we can be sure that it will either perform the intended cast, or fail at compile time.
Add `LayoutS::is_uninhabited` and use it
Use accessors for the things that accessors are good at: reducing everyone's need to be nosy and peek at the internals of every data structure.
compiler: Add rustc_abi dependence to the compiler
Depend on rustc_abi in compiler crates that use it indirectly but have not yet taken on that dependency, and are not *significantly* entangled in my other PRs. This leaves an "excise rustc_target" step after the dust settles.
Add a new trait `proc_macro::ToTokens`
Tracking issue #130977
This PR adds a new trait `ToTokens`, implemented for types that can be interpolated inside a `quote!` invocation.
```rust
impl ToTokens for TokenTree
impl ToTokens for TokenStream
impl ToTokens for Literal
impl ToTokens for Ident
impl ToTokens for Punct
impl ToTokens for Group
impl<T: ToTokens + ?Sized> ToTokens for &T
impl<T: ToTokens + ?Sized> ToTokens for &mut T
impl<T: ToTokens + ?Sized> ToTokens for Box<T>
impl<T: ToTokens + ?Sized> ToTokens for Rc<T>
impl<T: ToTokens + ToOwned + ?Sized> ToTokens for Cow<'_, T>
impl<T: ToTokens> ToTokens for Option<T>
impl ToTokens for u{8,16,32,64,128}
impl ToTokens for i{8,16,32,64,128}
impl ToTokens for f{32,64}
impl ToTokens for {u,i}size
impl ToTokens for bool
impl ToTokens for char
impl ToTokens for str
impl ToTokens for String
impl ToTokens for CStr
impl ToTokens for CString
```
~This PR also implements the migration mentioned in the tracking issue, replacing `Extend<Token{Tree,Stream}>` with `Extend<T: ToTokens>`, and replacing `FromIterator<Token{Tree,Stream}>` with `FromIterator<T: ToTokens>`.~
**UPDATE**: Reverted.
```diff
-impl FromIterator<TokenTree> for TokenStream
-impl FromIterator<TokenStream> for TokenStream
+impl<T: ToTokens> FromIterator<T> for TokenStream
-impl Extend<TokenTree> for TokenStream
-impl Extend<TokenStream> for TokenStream
+impl<T: ToTokens> Extend<T> for TokenStream
```
I'm going to leave some comments in the review where I'm unsure and concerned.
r? ``@dtolnay``
CC ``@tgross35``
Lower AST node id only once
Fixes#96346.
I basically followed the given instructions except the inline part.
`lower_jump_destination` can't reuse local existing `HirId` due to unknown name resolution result so I created an additional mapping for labels.
r? ```@cjgillot```
Rollup of 4 pull requests
Successful merges:
- #131391 (Stabilize `isqrt` feature)
- #132248 (rustc_transmute: Directly use types from rustc_abi)
- #132252 (compiler: rename LayoutS to LayoutData)
- #132253 (Known-bug test for `keyword_idents` lint not propagating to other files)
r? `@ghost`
`@rustbot` modify labels: rollup
Known-bug test for `keyword_idents` lint not propagating to other files
Known-bug test for `keyword_idents` lint not propagating to other files when configured via attribute (#132218).
compiler: rename LayoutS to LayoutData
Bid `LayoutS` goodbye because it looks like a typo.
`LayoutS` is the last of the types that use the "`{TypeName}` is the interned type, `{TypeName}S` is the backing data that is interned" convention. This is pretty confusing to those not intimately familiar with the history of rustc's names for its types over time, and doubly so now that there are no other examples in the tree. Abolish this convention.
