| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
do not trust download-rustc=if-unchanged on CI for now
See https://github.com/rust-lang/rust/issues/131658.
Once https://github.com/rust-lang/rust/pull/131831 lands this will be unnecessary, for until then, better safe than sorry.
r? `@onur-ozkan`
Cc `@rust-lang/bootstrap`
|
|
|
|
|
|
Revert #132772 to fix unknown git commit hash
Reverts #132772 to address #132845, we seem to have unintentionally omitted commit hash.
r? `@onur-ozkan`
|
|
|
|
This reverts commit c435fa8c4b55f0f8ef8e2e839ce7de960613267e, reversing
changes made to 88acd493f9dbbc8228db2b123c9b4132a995de92.
Seems to have unintentionally omitted commit hash leading to
<https://github.com/rust-lang/rust/pull/132772>.
|
|
Rollup of 2 pull requests
Successful merges:
- #132136 (ABI compatibility: remove section on target features)
- #132816 (Dont suggest `use<impl Trait>` when we have an edition-2024-related borrowck issue)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Dont suggest `use<impl Trait>` when we have an edition-2024-related borrowck issue
#131186 implements some machinery to detect in borrowck when we may have RPIT overcaptures due to edition 2024, and suggests adding `+ use<'a, T>` to go back to the edition 2021 capture rules. However, we weren't filtering out cases when there are APITs in scope.
This PR implements a more sophisticated diagnostic where we will suggest turning any APITs in scope into type parameters, and applies this to both the borrowck error note, and to the `impl_trait_overcaptures` migration lint.
cc #132809
|
|
ABI compatibility: remove section on target features
Once https://github.com/rust-lang/rust/pull/127731 lands, we will properly diagnose ABI issues caused by target feature mismatch (at least on tier 1 targets). So I'd say we can remove the corresponding part of the docs here -- this is now something the compiler can take care of, so programmers don't need to be concerned. For now this is just a lint, but that's just a transition period, like in prior cases where we fix I-unsound bugs by adding a new check that goes through the "future incompatibility" stages. We have decided that it's actually a bug that we have ABI risks around target features, and we shouldn't document that bug as-if it was intended behavior.
Cc `@rust-lang/opsem` `@chorman0773` `@veluca93`
|
|
Rollup of 6 pull requests
Successful merges:
- #131258 (Stabilize s390x inline assembly)
- #132801 (interpret: get_alloc_info: also return mutability)
- #132823 (require const_impl_trait gate for all conditional and trait const calls)
- #132824 (Update grammar in wasm-c-abi's compiler flag documentation)
- #132825 (Exclude relnotes-tracking-issue from needs-triage)
- #132828 (Additional tests to ensure let is rejected during parsing)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Additional tests to ensure let is rejected during parsing
In the original stabilization PR, @ `compiler-errors` has [pointed out](https://github.com/rust-lang/rust/pull/94927#issuecomment-1165156328) that #97295 wasn't enough to address the concerns about having `let` in expressions being rejected at parsing time, instead of later.
Thankfully, since then the situation has been greatly improved by #115677. This PR adds some additional tests to `disallowed-positions.rs`, and adds two additional revisions to the "normal" case which is now given the `feature` name:
* `no_feature`: Added to incorporate `disallowed-positions-without-feature-gate.rs` into the file, reducing duplication.
* `nothing`: like feature, but all functions are cfg'd out. Ensures that the errors are really emitted during parsing.
cc tracking issue #53667
|
|
Exclude relnotes-tracking-issue from needs-triage
|
|
Update grammar in wasm-c-abi's compiler flag documentation
This PR adjusts the grammar of the `wasm-c-abi` compiler flag documentation. See the inline comments within the PR for details.
|
|
r=fee1-dead,compiler-errors
require const_impl_trait gate for all conditional and trait const calls
Alternative to https://github.com/rust-lang/rust/pull/132786.
`@compiler-errors` this is basically what I meant with my proposals. I found it's easier to express this in code than English. ;)
r? `@compiler-errors`
|
|
interpret: get_alloc_info: also return mutability
This will be needed for https://github.com/rust-lang/miri/pull/3971
This then tuned into a larger refactor where we introduce a new type for the `get_alloc_info` return data, and we move some code to methods on `GlobalAlloc` to avoid duplicating it between the validity check and `get_alloc_info`.
|
|
Stabilize s390x inline assembly
This stabilizes inline assembly for s390x (SystemZ).
Corresponding reference PR: https://github.com/rust-lang/reference/pull/1643
---
From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335
> Each architecture needs to be reviewed before stabilization:
> - It must have clobber_abi.
Done in https://github.com/rust-lang/rust/pull/130630.
> - It must be possible to clobber every register that is normally clobbered by a function call.
Done in the PR that added support for clobber_abi.
> - Generally review that the exposed register classes make sense.
The followings can be used as input/output:
- `reg` (`r[0-10]`, `r[12-14]`): General-purpose register
- `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context
This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See https://github.com/rust-lang/rust/pull/119431 for details.
- `freg` (`f[0-15]`): Floating-point register
The followings are clobber-only:
- `vreg` (`v[0-31]`): Vector register
Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (https://github.com/rust-lang/rust/issues/130869 tracks unstable stuff here)
- `areg` (`a[2-15]`): Access register
All of the above register classes except `reg_addr` are needed for `clobber_abi`.
The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM):
- `r11`: frame pointer
- `r15`: stack pointer
- `a0`, `a1`: Reserved for system use
- `c[0-15]` (control register) Reserved by the kernel
Although not listed in the above requirements, `preserves_flags` is implemented in https://github.com/rust-lang/rust/pull/111331.
---
cc ``@uweigand``
r? ``@Amanieu``
``@rustbot`` label +O-SystemZ +A-inline-assembly
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
Emit warning when calling/declaring functions with unavailable vectors.
On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)
As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code.
This commit makes it a post-monomorphization future-incompat warning to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.
See the [nomination comment](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187) for more discussion.
Part of #116558
r? RalfJung
|
|
Update cargo
16 commits in 0310497822a7a673a330a5dd068b7aaa579a265e..4a2d8dc636445b276288543882e076f254b3ae95
2024-11-01 19:27:56 +0000 to 2024-11-09 19:10:33 +0000
- test: adjust `cargo_test_env` to unblock rust submodule update (rust-lang/cargo#14803)
- feat(warnings): add build.warnings option (rust-lang/cargo#14388)
- Revert "feat: Add `CARGO_RUSTC_CURRENT_DIR`" (rust-lang/cargo#14799)
- CI: make the `lint-docs` job required (rust-lang/cargo#14797)
- Switch CI from bors to merge queue (rust-lang/cargo#14718)
- docs(test): Document Execs assertions based on port effort (rust-lang/cargo#14793)
- fix(test): Make redactions consistent with snapbox (rust-lang/cargo#14790)
- test(gc): Update remaining unordered tests to snapbox (rust-lang/cargo#14785)
- Normalize the `target` paths (rust-lang/cargo#14497)
- rustfix: replace special-case duplicate handling with error (rust-lang/cargo#14782)
- test: Update some emaining unordered tests to snapbox (rust-lang/cargo#14781)
- Change config paths to only check CARGO_HOME for cargo-script (rust-lang/cargo#14749)
- Enable transfer feature in triagebot (rust-lang/cargo#14777)
- Add transactional semantics to `rustfix` (rust-lang/cargo#14747)
- doc: fix `GlobalContext` reference (rust-lang/cargo#14773)
- chore: update handlebars to v6, fix build error (rust-lang/cargo#14772)
|
|
|
|
Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #132341 (Reject raw lifetime followed by `'`, like regular lifetimes do)
- #132363 (Enforce that raw lifetimes must be valid raw identifiers)
- #132744 (add regression test for #90781)
- #132754 (Simplify the internal API for declaring command-line options)
- #132772 (use `download-rustc="if-unchanged"` as a global default)
- #132774 (Use lld with non-LLVM backends)
- #132799 (Make `Ty::primitive_symbol` recognize `str`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Make `Ty::primitive_symbol` recognize `str`
Make `Ty::primitive_symbol` recognize `str`, which makes `str` eligible for the "expected primitive, found local type" (and vice versa) [diagnostic](https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/error_reporting/infer/mod.rs#L1430-L1437) that already exists for other primitives.
<details><summary> diagnostic difference</summary>
```rs
#[allow(non_camel_case_types)]
struct str;
fn foo() {
let _: &str = "hello";
let _: &core::primitive::str = &str;
}
```
`rustc --crate-type lib --edition 2021 a.rs`
Current nightly:
```rs
error[E0308]: mismatched types
--> a.rs:5:19
|
5 | let _: &str = "hello";
| ---- ^^^^^^^ expected `str`, found a different `str`
| |
| expected due to this
|
= note: expected reference `&str`
found reference `&'static str`
error[E0308]: mismatched types
--> a.rs:6:36
|
6 | let _: &core::primitive::str = &str;
| --------------------- ^^^^ expected `str`, found a different `str`
| |
| expected due to this
|
= note: expected reference `&str` (`str`)
found reference `&str` (`str`)
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0308`.
```
With this patch:
```rs
error[E0308]: mismatched types
--> a.rs:5:19
|
5 | let _: &str = "hello";
| ---- ^^^^^^^ expected `str`, found a different `str`
| |
| expected due to this
|
= note: str and `str` have similar names, but are actually distinct types
= note: str is a primitive defined by the language
note: `str` is defined in the current crate
--> a.rs:2:1
|
2 | struct str;
| ^^^^^^^^^^
error[E0308]: mismatched types
--> a.rs:6:36
|
6 | let _: &core::primitive::str = &str;
| --------------------- ^^^^ expected `str`, found a different `str`
| |
| expected due to this
|
= note: str and `str` have similar names, but are actually distinct types
= note: str is a primitive defined by the language
note: `str` is defined in the current crate
--> a.rs:2:1
|
2 | struct str;
| ^^^^^^^^^^
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0308`.
```
</details>
|
|
Use lld with non-LLVM backends
On arm64, Cranelift used to produce object files that don't work with lld. This has since been fixed. The GCC backend should always produce object files that work with lld unless lld for whatever reason drops GCC support. Most of the other more niche backends don't use cg_ssa's linker code at all. If they do and don't work with lld, they can always disable lld usage using a cli argument.
Without this commit using cg_clif is by default in a non-trivial amount of cases a perf regression on Linux due to ld.bfd being a fair bit slower than lld. It is possible to explicitly enable it without this commit, but most users are unlikely to do this.
|
|
use `download-rustc="if-unchanged"` as a global default
If `download-rustc` isn't explicitly set and the source is Git-managed, it should be totally okay to utilize "if-unchanged" behaviour. The "dist" profile already sets `download-rustc` to `false`, so this shouldn’t impact anything on CI.
This also resolves an unhandled case where `bootstrap` unexpectedly panics if `"if-unchanged"` was used with a non-Git source. Now we exits gracefully with an error message pointing the problem.
|
|
Simplify the internal API for declaring command-line options
The internal APIs for declaring command-line options are old, and intimidatingly complex. This PR replaces them with a single function that takes explicit `stability` and `kind` arguments, making it easier to see how each option is handled, and whether it is treated as stable or unstable.
We also don't appear to have any tests for the output of `rustc --help` and similar, so I've added a run-make test to verify that this PR doesn't change any output. (There is already a similar run-make test for rustdoc's help output.)
---
The librustdoc changes are simply adjusting to updated compiler APIs; no functional change intended.
---
A side-effect of these changes is that rustfmt can once again format the entirety of these option declaration lists, which it was not doing before.
|
|
add regression test for #90781
closes #90781
|
|
Enforce that raw lifetimes must be valid raw identifiers
Make sure that the identifier part of a raw lifetime is a valid raw identifier. This precludes `'r#_` and all module segment paths for now.
I don't believe this is compelling to support. This was raised by `@ehuss` in https://github.com/rust-lang/reference/pull/1603#discussion_r1822726753 (well, specifically the `'r#_` case), but I don't see why we shouldn't just make it consistent with raw identifiers.
|
|
Reject raw lifetime followed by `'`, like regular lifetimes do
See comment. We want to reject cases like `'r#long'id`, which currently gets interpreted as a raw lifetime (`'r#long`) followed by a lifetime (`'id`). This could have alternative lexes, such as an overlong char literal (`'r#long'`) followed by an identifier (`id`). To avoid committing to this in any case, let's reject the whole thing.
`@mattheww,` is this what you were looking for in https://github.com/rust-lang/reference/pull/1603#issuecomment-2339237325? I'd say ignore the details about the specific error message (the fact that this gets reinterpreted as a char literal is 🤷), just that because this causes a lexer error we're effectively saving syntactical space like you wanted.
|
|
Add discriminators to DILocations when multiple functions are inlined into a single point.
LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM.
This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling.
|
|
single point.
LLVM does not expect to ever see multiple dbg_declares for the same variable at the same
location with different values. proc-macros make it possible for arbitrary code,
including multiple calls that get inlined, to happen at any given location in the source
code. Add discriminators when that happens so these locations are different to LLVM.
This may interfere with the AddDiscriminators pass in LLVM, which is added by the
unstable flag -Zdebug-info-for-profiling.
Fixes #131944
|
|
Subtree sync for rustc_codegen_cranelift
Apart from a perf optimization for some crates (https://github.com/rust-lang/rustc_codegen_cranelift/pull/1541) not much changed this time as the last sync was less than a week ago.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
duplication with validity checking
|
|
sync_cg_clif-2024-11-09
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #132552 (Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file)
- #132745 (pointee_info_at: fix logic for recursing into enums)
- #132777 (try_question_mark_nop: update test for LLVM 20)
- #132785 (rustc_target: more target string fixes for LLVM 20)
- #132794 (Use a separate dir for r-a builds consistently in helix config)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Use a BufWriter in emit_module to reduce syscall overhead
|
|
|
|
Use a separate dir for r-a builds consistently in helix config
r? `@jieyouxu`
cc `@mrkajetanp`
Previously config used `build-rust-analyzer` for rustfmt and proc macros server, while not using it for actual `x check` commands.
This PR:
- Replaces the build dir with `build/rust-analyzer`
- This is just my preference
- Although I do think this is the nicest option: the directory is already git-ignored, `rm -fr ./build` removes everything, etc
- Uses said directory with the `x check` commands in helix r-a config
- Adds instructions on how to build rustfmt and proc macro server to the config
As of note, this is not what other configs do (like vscode's), however this _is_ what I would actually suggest to people (and what I'm actually using).
|
|
rustc_target: more target string fixes for LLVM 20
LLVM continues to clean these up, and we continue to make this consistent. This is similar to 9caced7badc337ced7ad89eb614621c39bd996e9 and e9853961452b56997cc127b51308879b9cd09482.
`@rustbot` label: +llvm-main
|
|
try_question_mark_nop: update test for LLVM 20
llvm/llvm-project@dd116369f646d023a2e7e5c145a1bed5dcf9a45c changes the IR of this test in a way that I don't think is bad, but needs adjusting.
r? `@nikic`
`@rustbot` label: +llvm-main
|
|
pointee_info_at: fix logic for recursing into enums
Fixes https://github.com/rust-lang/rust/issues/131834
The logic in `pointee_info_at` was likely written at a time when the null pointer optimization was the *only* enum layout optimization -- and as `Variant::Multiple` kept getting expanded, nobody noticed that the logic is now unsound.
The job of this function is to figure out whether there is a dereferenceable-or-null and aligned pointer at a given offset inside a type. So when we recurse into a multi-variant enum, we better make sure that all the other enum variants must be null! This is the part that was forgotten, and this PR adds it.
The reason this didn't explode in many ways so far is that our references only have 1 niche value (null), so it's not possible on stable to have a multi-variant enum with a dereferenceable pointer and other enum variants that are not null. But with `rustc_layout_scalar_valid_range` attributes one can force such a layout, and if `@the8472's` work on alignment niches ever lands, that will make this possible on stable.
|
