| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Revert "miri: make sure we can find link_section statics even for the local crate"
This PR reverts #126938 as [requested by its author](https://github.com/rust-lang/rust/issues/127052#issuecomment-2196793473), to fix the #127052 regression.
Fixes #127052
We should probably improve the [`used` rmake test(s)](https://github.com/rust-lang/rust/blob/57931e50409f9365791f7923a68f9ae1ec301c4c/tests/run-make/used/rmake.rs#L7) in the future, but this should do for now.
|
|
|
|
ignore `llvm::Lld` if lld is not enabled
People are having trouble ([ref. zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/MSVC.20Runtime.20mismatch.20when.20building.20LLD)) when they don't want to build `lld` for their custom distribution tarballs even with `lld = false` in their config.toml. This is because it is not controlled by `lld_enabled` flag. This change ensures that `llvm:Lld` is controlled by lld configuration.
Additionally, `lld = true` is set by default for dist profile, because we have been building it all along and this maintains that behavior.
try-job: x86_64-mingw
|
|
Migrate `use-suggestions-rust-2018`, `overwrite-input`, `lto-dylib-dep` and `many-crates-but-no-match` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Tighten `fn_decl_span` for async blocks
Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on #125078, but it fixes the problem in a more general way.
I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters.
r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol
|
|
Support fetching `Attribute` of items.
Fixes [https://github.com/rust-lang/project-stable-mir/issues/83](https://github.com/rust-lang/project-stable-mir/issues/83)
`rustc_ast::ast::Attribute` doesn't impl `Hash` and `Eq`. Thus it cannot be directly used as key of `IndexMap` in `rustc_smir::rustc_smir::Tables` and we cannot define stable `Attribute` as index to `rustc_ast::ast::Attribute` like `Span` and many other stable definitions.
Since an string (or tokens) and its span contain all info about an attribute, I defined a simple `Attribute` struct on stable side.
I choose to fetch attributes via `tcx::get_attrs_by_path()` due to `get_attrs()` is marked as deprecated and `get_attrs_by_name()` cannot handle name of multiple segments like `rustfmt::skip`.
r? `@celinval`
|
|
core: avoid `extern type`s in formatting infrastructure
```@RalfJung``` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837):
>How attached are y'all to using `extern type` in the formatting machinery?
Seems like this was introduced a [long time ago](https://github.com/rust-lang/rust/commit/34ef8f5441d5335c4177abd622383ed34a6e9315). However, it's also [not really compatible with Stacked Borrows](https://github.com/rust-lang/unsafe-code-guidelines/issues/256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](https://github.com/rust-lang/rust/issues/126814#issuecomment-2183816373) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere...
>
> The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`).
This PR does just that.
r? ```@RalfJung```
|
|
r=estebank,workingjubilee
patchable-function-entry: Add unstable compiler flag and attribute
Tracking issue: #123115
Add the -Z patchable-function-entry compiler flag and the #[patchable_function_entry(prefix_nops = m, entry_nops = n)] attribute.
Rebased and adjusted the canditate implementation to match changes in the RFC.
|
|
|
|
|
|
Update browser-ui-test version to `0.18.0`
Should help with #126436.
r? `@notriddle`
|
|
|
|
|
|
|
|
r=Kobzol
Migrate `run-make/invalid-library` to `rmake.rs`
Part of #121876.
r? `@jieyouxu`
try-job: x86_64-msvc
|
|
ast: Standardize visiting order
Order: ID, attributes, inner nodes in source order if possible, tokens, span.
Also always use exhaustive matching in visiting infra, and visit some discovered missing nodes.
Unlike https://github.com/rust-lang/rust/pull/125741 this shouldn't affect anything serious like `macro_rules` scopes.
|
|
|
|
|
|
Remove `__rust_force_expr`.
This was added (with a different name) to improve an error message. It is no longer needed -- removing it changes the error message, but overall I think the new message is no worse:
- the mention of `#` in the first line is a little worse,
- but the extra context makes it very clear what the problem is, perhaps even clearer than the old message,
- and the removal of the note about the `expr` fragment (an internal detail of `__rust_force_expr`) is an improvement.
Overall I think the error is quite clear and still far better than the old message that prompted #61933, which didn't even mention patterns.
The motivation for this is #124141, which will cause pasted metavariables to be tokenized and reparsed instead of the AST node being cached. This change in behaviour occasionally has a non-zero perf cost, and `__rust_force_expr` causes the tokenize/reparse step to occur twice. Removing `__rust_force_expr` greatly reduces the extra overhead for the `deep-vector` benchmark.
r? ```@oli-obk```
|
|
Some `Nonterminal` removal precursors
Small things to prepare for #124141, more or less.
r? ```@oli-obk```
|
|
coverage: Make `#[coverage(..)]` apply recursively to nested functions
This PR makes the (currently-unstable) `#[coverage(off)]` and `#[coverage(on)]` attributes apply recursively to all nested functions/closures, instead of just the function they are directly attached to.
Those attributes can now also be applied to modules and to impl/impl-trait blocks, where they have no direct effect, but will be inherited by all enclosed functions/closures/methods that don't override the inherited value.
---
Fixes #126625.
|
|
|
|
|
|
|
|
Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383)
Let's give this another try! The [previous stabilization attempt](https://github.com/rust-lang/rust/pull/99063) was stalled by some unresolved questions. These have been discussed in a [lang team](https://github.com/rust-lang/lang-team/issues/191) meeting. The last open question, regarding the semantics of the `#[expect]` attribute was decided on in https://github.com/rust-lang/rust/issues/115980
I've just updated the [stabilization report](https://github.com/rust-lang/rust/issues/54503#issuecomment-1179563964) with the discussed questions and decisions. Luckily, the decision is inline with the current implementation.
This hopefully covers everything. Let's hope that the CI will be green like the spring.
fixes #115980
fixes #54503
---
r? `@wesleywiser`
Tacking Issue: https://github.com/rust-lang/rust/issues/54503
Stabilization Report: https://github.com/rust-lang/rust/issues/54503#issuecomment-1179563964
Documentation Update: https://github.com/rust-lang/reference/pull/1237
<!--
For Clippy:
changelog: [`allow_attributes`]: Is now available on stable, since the `lint_reasons` feature was stabilized
changelog: [`allow_attributes_without_reason`]: Is now available on stable, since the `lint_reasons` feature was stabilized
-->
---
Roses are red,
Violets are blue,
Let's expect lints,
With reason clues
|
|
|
|
Id, attributes, inner nodes in source order if possible, tokens, span.
Also always use exhaustive matching in visiting infra, and visit some missing nodes.
|
|
Remove more `PtrToPtr` casts in GVN
This addresses two things I noticed in MIR:
1. `NonNull::<T>::eq` does `(a as *mut T) == (b as *mut T)`, but it could just compare the `*const T`s, so this removes `PtrToPtr` casts that are on both sides of a pointer comparison, so long as they're not fat-to-thin casts.
2. `NonNull::<T>::addr` does `transmute::<_, usize>(p as *const ())`, but so long as `T: Thin` that cast doesn't do anything, and thus we can directly transmute the `*const T` instead.
r? mir-opt
|
|
chenyukang:yukang-fix-126756-unsafe-suggestion-error, r=spastorino
Fix bad replacement for unsafe extern block suggestion
Fixes #126756
r? ``@spastorino``
link #123743
|
|
Don't ICE during RPITIT refinement checking for resolution errors after normalization
#126670 shows a case where resolution errors after normalization can happen during RPITIT refinement checking. Our tests didn't reach this path before, and we explicitly ICEd until we had a test. We can now delay a bug since we're sure it is reachable and have the test from the isue.
The comment I added likely still needs more expert wordsmithing.
r? ``@compiler-errors`` who's making me work during vacation (j/k).
Fixes #126670
|
|
Migrate `lto-empty`, `invalid-so` and `issue-20626` `run-make` tests to rmake.rs
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
|
|
Change E0369 to give note informations for foreign items.
Change E0369 to give note informations for foreign items.
Make it easy for developers to understand why the binop cannot be applied.
fixes #125631
|
|
r=compiler-errors
Fix a span in `parse_ty_bare_fn`.
It currently goes one token too far.
Example: line 259 of `tests/ui/abi/compatibility.rs`:
```
test_abi_compatible!(fn_fn, fn(), fn(i32) -> i32);
```
This commit changes the span for the second element from `fn(),` to `fn()`, i.e. removes the extraneous comma.
This doesn't affect any tests. I found it while debugging some other code. Not a big deal but an easy fix so I figure it worth doing.
r? ``@spastorino``
|
|
|
|
These attributes apply to all enclosed functions/methods/closures, unless
explicitly overridden by another coverage attribute.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #126618 (Mark assoc tys live only if the corresponding trait is live)
- #126746 (Deny `use<>` for RPITITs)
- #126868 (not use offset when there is not ends with brace)
- #126884 (Do not ICE when suggesting dereferencing closure arg)
- #126893 (Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level)
- #126915 (Don't suggest awaiting in closure patterns)
- #126943 (De-duplicate all consecutive native libs regardless of their options)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
It currently goes one token too far.
Example: line 259 of `tests/ui/abi/compatibility.rs`:
```
test_abi_compatible!(fn_fn, fn(), fn(i32) -> i32);
```
This commit changes the span for the second element from `fn(),` to
`fn()`, i.e. removes the extraneous comma.
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
Delegation: ast lowering refactor
refactoring changes for https://github.com/rust-lang/rust/pull/126699
r? ```@petrochenkov```
|
|
Detect unused structs which derived Default
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Fixes #98871
|
|
|
|
|
|
|
|
tests
|
