Add `FnContext` in parser for diagnostic
Fixesrust-lang/rust#144968
Inspired by https://github.com/rust-lang/rust/issues/144968#issuecomment-3156094581, I implemented `FnContext` to indicate whether a function should have a self parameter, for example, whether the function is a trait method, whether it is in an impl block. And I removed the outdated note.
I made two commits to show the difference.
cc ``@estebank`` ``@djc``
r? compiler
Resolve the prelude import in `build_reduced_graph`
This pr tries to resolve the prelude import at the `build_reduced_graph` stage.
Part of batched import resolution in rust-lang/rust#145108 (cherry picked commit) and maybe needed for rust-lang/rust#139493.
r? petrochenkov
llvm: Accept new LLVM lifetime format
In llvm/llvm-project#150248 LLVM removed the size parameter from the lifetime format. Tolerate not having that size parameter.
strip prefix of temporary file names when it exceeds filesystem name length limit
When doing lto, rustc generates filenames that are concatenating many information.
In the case of this testcase, it is concatenating crate name and rust file name, plus some hash, and the extension. In some other cases it will concatenate even more information reducing the maximum effective crate name to about 110 chars on linux filesystems where filename max length is 255
This commit is ensuring that the temporary file names are limited in size, while still reasonably ensuring the unicity (with hashing of the stripped part)
Fix: rust-lang/rust#49914
Fix tail calls to `#[track_caller]` functions
We want `#[track_caller]` to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls.
The only way to achieve this that I can see is:
- we forbid tail calls in functions which are marked with `#[track_caller]` (already implemented)
- tail-calling a `#[track_caller]` marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr)
Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc ```@saethlin,``` rust-lang/rust#131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated)
Additionally I added a lint, although I don't think it's strictly necessary.
Alternative to rust-lang/rust#144762 (and thus closesrust-lang/rust#144762)
Fixes https://github.com/rust-lang/rust/issues/144755
compiler: Allow `extern "interrupt" fn() -> !`
While reviewing rust-lang/rust#142633 I overlooked a few details because I was kind of excited.
- Fixesrust-lang/rust#143072
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix#122159.
Patterns: represent constants as valtrees
Const patterns are always valtrees now. Let's represent that in the types. We use `ty::Value` for this since it nicely packages value and type, and has some convenient methods.
Cc `@Nadrieril` `@BoxyUwU`
Add infrastructure to apply a derive macro to arguments, consuming and
returning a `TokenTree` only.
Handle `SyntaxExtensionKind::MacroRules` when expanding a derive, if the
macro's kinds support derive.
Add tests covering various cases of `macro_rules` derives.
Note that due to a pre-existing FIXME in `expand.rs`, derives are
re-queued and some errors get emitted twice. Duplicate diagnostic
suppression makes them not visible, but the FIXME should still get
fixed.
cfg_select: Support unbraced expressions
Tracking issue for `cfg_select`: rust-lang/rust#115585
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
---
I'm not sure whether deciding to extend `cfg_select!` in this way is T-lang or T-libs-api. I've labeled for both, with the request that both teams don't block on each other. :)
Fix test intrinsic-raw_eq-const-bad for big-endian
The test fails on s390x and presumably other big-endian systems, due to print of raw values. To fix the tests remove the raw output values in the error note with normalize-stderr.
Include whitespace in "remove |" suggestion and make it hidden
Tweak error rendering of patterns with an extra `|` on either end.
Built on #137409. Only last commit is relevant.
? ``@compiler-errors``
Rework target checking for built-in attributes
This is a refactoring of target checking for built-in attributes.
This PR has the following goals:
- Only refactor the 80% of the attributes that are simple to target check. More complicated ones like `#[repr]` will be in a future PR. Tho I have written the code in such a way that this will be possible to add in the future.
- No breaking changes.
- This part of the codebase is not very well tested though, we can do a crater run if we want to be sure.
- I've spotted quite a few weird situations (like I don't think an impl block should be deprecated?). We can propose fixing these to in a future PR
Fixes https://github.com/rust-lang/rust/issues/143780
Fixes https://github.com/rust-lang/rust/issues/138510
I've split it in commits and left a description on some of the commits to help review.
r? `@jdonszelmann`
Stabilize `sse4a` and `tbm` target features
This PR stabilizes the feature flag `sse4a_target_feature` and `tbm_target_feature` (tracking issue rust-lang/rust#44839).
# Public API
The 2 `x86` target features `sse4a` and `tbm`
Also, these were added in LLVM2.6 and LLVM3.4-rc1, respectively, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now. The intrinsics were stabilized *long* ago, in 1.27.0
Reference PR:
- https://github.com/rust-lang/reference/pull/1949
cc `@rust-lang/lang`
`@rustbot` label I-lang-nominated
r? lang
Currently they are skipped, which is a bit weird, and it sometimes
causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all
regions are now printed as `'_` in non-optional places. Not perfect, but
better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the
`PASS_NAMES` sanity check still works. It is also renamed as
`simplify_pass_type_name` and made non-const, because it doesn't need
to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as
`should_print_optional_region`, which makes it clearer that it only
applies to some regions.
Fixes#145168.
Suppress wrapper suggestion when expected and actual ty are the same adt and the variant is unresolved
Fixesrust-lang/rust#145294
I initially tried the desired suggestion in this issue, but since that suggestion occurs in the expected type, it is inappropriate to suggest for expected expressions (see other suggest methods in the same file). I believe that suppressing the incorrect suggestion is the more appropriate choice here.
I opted for a slightly more general approach: when the expected type and actual type are the same ADT (e.g., both are Result in this example), we assume that code tend to compare the internal generic parameters(i.e. `Option<&str>` vs `Option<String>`, instead of `E = _` vs `Result<Option<String>>>`). When `E` is an unresolved infer type in the expected type (`_` in this example), we should not wrapp the actual type.
Two commits show the difference.
r? compiler
rustdoc: Allow multiple references to a single footnote
Multiple references to a single footnote is a part of GitHub Flavored Markdown syntax (although not explicitly documented as well as regular footnotes, it is implemented in GitHub's fork of CommonMark) and not prohibited by rustdoc.
cf. <587a12bb54/test/extensions.txt (L762-L780)>
However, using it makes multiple `sup` elements with the same `id` attribute, which is invalid per the HTML specification.
Still, not only this is a valid GitHub Flavored Markdown syntax, this is helpful on certain cases and actually tested (accidentally) in `tests/rustdoc/footnote-reference-in-footnote-def.rs`.
This commit keeps track of the number of references per footnote and gives unique ID to each reference.
It also emits *all* back links from a footnote to its references as "↩" (return symbol) plus a numeric list in superscript.
As a known limitation, it assumes that all references to a footnote are rendered (this is not always true if a dangling footnote has one or more references but considered a reasonable compromise).
Also note that, this commit is designed so that no HTML changes will occur unless multiple references to a single footnote is actually used.
