Hack out effects support for old solver
Opening this for vibes ✨
Turns out that a basic, somewhat incomplete implementation of host effects is achievable in the old trait solver pretty easily. This should be sufficient for us to use in the standard library itself.
Regarding incompleteness, maybe we should always treat host predicates as ambiguous in intercrate mode (at least in the old solver) to avoid any worries about accidental impl overlap or something.
r? ```@lcnr``` cc ```@fee1-dead```
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**
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).
fix various linker warnings
separated out from https://github.com/rust-lang/rust/pull/119286; this doesn't have anything user-facing, i just want to land these changes so i can stop rebasing them.
r? `@bjorn3`
Remove `ObligationCause::span()` method
I think it's an incredibly confusing footgun to expose both `obligation_cause.span` and `obligation_cause.span()`. Especially because `ObligationCause::span()` (the method) seems to just be hacking around a single quirk in the way we set up obligation causes for match arms.
First commit removes the need for that hack, with only one diagnostic span changing (but IMO not really getting worse -- I'd argue that it was already confusing).
Much like the previous commit.
I think the removal of "the token" in each message is fine here. There
are many more error messages that mention tokens without saying "the
token" than those that do say it.
By using `token_descr`, as is done for many other errors, we can get
slightly better descriptions in error messages, e.g.
"macro expansion ignores token `let` and any following" becomes
"macro expansion ignores keyword `let` and any tokens following".
This will be more important once invisible delimiters start being
mentioned in error messages -- without this commit, that leads to error
messages such as "error at ``" because invisible delimiters are
pretty printed as an empty string.
this makes it much easier to understand test failures.
before:
```
diff of stderr:
1 error: linking with `LINKER` failed: exit status: 1
2 |
- ld: Undefined symbols:
4 _CFRunLoopGetTypeID, referenced from:
5 clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
after:
```
=== HAYSTACK ===
error: linking with `cc` failed: exit status: 1
|
= note: use `--verbose` to show all linker arguments
= note: Undefined symbols for architecture arm64:
"_CFRunLoopGetTypeID", referenced from:
main::main::hbb553f5dda62d3ea in main.main.d17f5fbe6225cf88-cgu.0.rcgu.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: aborting due to 1 previous error
=== NEEDLE ===
_CFRunLoopGetTypeID\.?, referenced from:
thread 'main' panicked at /Users/jyn/git/rust-lang/rust/tests/run-make/linkage-attr-framework/rmake.rs:22:10:
needle was not found in haystack
```
this also fixes a failure related to missing whitespace; we don't actually care about whitespace in this test.
Cleanup: Move an impl-Trait check from AST validation to AST lowering
Namely the one that rejects `impl Trait` in qself types and non-final path segments.
There's no good reason to perform this during AST validation.
We have better infrastructure in place in the AST lowerer (`ImplTraitContext`).
This shaves off a lot of code.
We now lower `impl Trait` in bad positions to `{type error}` which allows us to
remove a special case from HIR ty lowering.
Coincidentally fixes#126725. Well, it only *masks* it by passing `{type error}` to HIR analysis instead of a "bad" opaque. I was able to find a new reproducer for it. See the issue.
Rename macro `SmartPointer` to `CoercePointee`
As per resolution #129104 we will rename the macro to better reflect the technical specification of the feature and clarify the communication.
- `SmartPointer` is renamed to `CoerceReferent`
- `#[pointee]` attribute is renamed to `#[referent]`
- `#![feature(derive_smart_pointer)]` gate is renamed to `#![feature(derive_coerce_referent)]`.
- Any mention of `SmartPointer` in the file names are renamed accordingly.
r? `@compiler-errors`
cc `@nikomatsakis` `@Darksonn`
Rollup of 4 pull requests
Successful merges:
- #132123 (allow type-based search on foreign functions)
- #132183 (Fix code HTML items making big blocks if too long)
- #132192 (expand: Stop using artificial `ast::Item` for macros loaded from metadata)
- #132205 (docs: Correctly link riscv32e from platform-support.md)
r? `@ghost`
`@rustbot` modify labels: rollup
allow type-based search on foreign functions
fixes https://github.com/rust-lang/rust/issues/131804
preferably will be merged after #129708, but that may take a while to be approved due to being a new feature, whereas this is definitely a bug, and should be fixed.
Replace some LLVMRust wrappers with calls to the LLVM C API
This PR removes the LLVMRust wrapper functions for getting/setting linkage and visibility, and replaces them with direct calls to the corresponding functions in LLVM's C API.
To make this convenient and sound, two pieces of supporting code have also been added:
- A simple proc-macro that derives `TryFrom<u32>` for fieldless enums
- A wrapper type for C enum values returned by LLVM functions, to ensure soundness if LLVM returns an enum value we don't know about
In a few places, the use of safe wrapper functions means that an `unsafe` block is no longer needed, so the affected code has changed its indentation level.
Fixes#132203
This is a compatibility hack, because I think the new behavior is better.
When an A `include_str!` B, and B `include_str!` C, the path to C should
be resolved relative to B, not A. That's how `include!` itself works,
so that's how `include_str!` with should work.
rustc_target: Add pauth-lr aarch64 target feature
Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time.
r? `@Amanieu`
(Big performance change) Do not run lints that cannot emit
Before this change, adding a lint was a difficult matter because it always had some overhead involved. This was because all lints would run, no matter their default level, or if the user had `#![allow]`ed them. This PR changes that. This change would improve both the Rust lint infrastructure and Clippy, but Clippy will see the most benefit, as it has about 900 registered lints (and growing!)
So yeah, with this little patch we filter all lints pre-linting, and remove any lint that is either:
- Manually `#![allow]`ed in the whole crate,
- Allowed in the command line, or
- Not manually enabled with `#[warn]` or similar, and its default level is `Allow`
As some lints **need** to run, this PR also adds **loadbearing lints**. On a lint declaration, you can use the ``@eval_always` = true` marker to label it as loadbearing. A loadbearing lint will never be filtered (it will always run)
Fixes#106983
Deny calls to non-`#[const_trait]` methods in MIR constck
This is a (potentially temporary) fix that closes off the mismatch in assumptions between MIR constck and typeck which does the const traits checking. Before this PR, MIR constck assumed that typeck correctly handled all calls to trait methods in const contexts if effects is enabled. That is not true because typeck only correctly handles callees that are const. For non-const callees (such as methods in a non-const_trait), typeck had never created an error.
45089ec19e/compiler/rustc_hir_typeck/src/callee.rs (L876-L877)
I called this potentially temporary because the const checks could be moved to HIR entirely. Alongside the recent refactor in const stability checks where that component could be placed would need more discussion. (cc ```@compiler-errors``` ```@RalfJung)```
Tests are updated, mainly due to traits not being const in core, so tests that call them correctly error.
This fixes https://github.com/rust-lang/project-const-traits/issues/12.
