| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
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 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.
|
|
Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file
This adds the following three unstable target features:
- `v9`: SPARC-V9 instructions ([LLVM definition][sparc-v9])
- Relevant to https://github.com/rust-lang/rust/pull/131222#issuecomment-2453310963
- Relevant to https://github.com/rust-lang/rust/pull/132472#discussion_r1832606081
- This is also needed to implement https://github.com/taiki-e/atomic-maybe-uninit/pull/31 (depends on inline assembly support) more robustly.
- `v8plus`: SPARC-V8+ ABI ([LLVM definition][sparc-v8plus])
- This is added in LLVM 20. In LLVM 19 and older, it is emulated to work the same way as LLVM in each LLVM version.
- See https://github.com/rust-lang/rust/issues/132585#issuecomment-2453926257 for more.
- `leoncasa`: CASA instruction[^1] of LEON3 and LEON4 processors ([LLVM definition][sparc-leoncasa], LLVM feature name: `hasleoncasa`)
- This is needed to implement https://github.com/taiki-e/atomic-maybe-uninit/pull/31 (depends on inline assembly support) more robustly.
[^1]: Atomic CAS instruction
[sparc-v9]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-v8plus]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-leoncasa]: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/LeonFeatures.td#L32-L37
|
|
Trim and tidy includes in `rustc_llvm`
These includes tend to accumulate over time, and are usually only removed when something breaks in a new LLVM version, so it's nice to clean them up manually once in a while.
General strategy used for this PR:
- Remove all includes from `LLVMWrapper.h` that aren't needed by the header itself, transplanting them to individual source files as necessary.
- For each source file, temporarily remove each include if doing so doesn't cause a compile error.
- If a “required” include looks like it shouldn't be needed, try replacing it with its sub-includes, then trim that list.
- After doing all of the above, go back and re-add any removed include if the file does actually use things defined in that header, even if the header happens to also be included by something else.
|
|
Rollup of 5 pull requests
Successful merges:
- #132755 (Do not reveal opaques in the param-env, we got lazy norm instead)
- #132757 (Get rid of `check_opaque_type_well_formed`)
- #132760 (Don't suggest `.into_iter()` on iterators)
- #132778 (update io::Error::into_inner to acknowledge io::Error::other)
- #132780 (use verbose for path separator suggestion)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
use verbose for path separator suggestion
A single `-` of suggestion underlining that is adjacent to a much more significant `^^^` underlying of the LHS path component is hard to distinguish. IMO this presents much more cleanly when it's verbose, especially because it's a *replacment* suggestion.
r? estebank
|
|
update io::Error::into_inner to acknowledge io::Error::other
|
|
Don't suggest `.into_iter()` on iterators
This makes the the suggestion to call `.into_iter()` only consider unsatisfied `Iterator` bounds for the receiver type itself. That way, it ignores predicates generated by trying to auto-ref the receiver (the result of which usually won't implement `Iterator`).
Fixes #127511
Unfortunately, the error in that case is still confusing: it labels `Iterator` as an unsatisfied bound because `&impl Iterator: Iterator` can't be satisfied, despite that not being required or helpful. I'd like to handle that in a separate PR. ~~I'm hoping fixing #124802 will fix it too.~~ It doesn't look connected to that issue. Still, I think it'd be clearest to visually distinguish unsatisfied predicates from different attempts at `pick_method`; I'll make a PR for that soon.
|
|
Get rid of `check_opaque_type_well_formed`
Instead, replicate it by improving the span of the opaque in `check_opaque_meets_bounds`.
This has two consequences:
1. We now prefer "concrete type differs" errors, since we'll hit those first before we check the opaque is WF.
2. Spans have gotten slightly worse.
Specifically, (2.) could be improved by adding a new obligation cause that explains that the definition's environment has stronger assumptions than the declaration.
r? lcnr
|
|
Do not reveal opaques in the param-env, we got lazy norm instead
r? lcnr
|
|
Make `RustString` an extern type to avoid `improper_ctypes` warnings
Currently, any FFI function that uses `&RustString` needs to also add `#[ignore(improper_ctypes)]` to silence a warning.
The warning is not _completely_ bogus, because `RustString` contains `Vec<u8>` and therefore does not have a guaranteed layout. But we have no way of telling the lint that this doesn't matter, because the C++ code only uses that pointer opaquely and never relies on its underlying layout.
Ideally there would be some way to silence `improper_ctypes` at the type-definition site. But because there isn't, casting to and from a separate extern type is better than having to annotate every single use site.
|
|
|
|
|
|
|
|
|
|
LLVM continues to clean these up, and we continue to make this
consistent. This is similar to 9caced7badc337ced7ad89eb614621c39bd996e9
and e9853961452b56997cc127b51308879b9cd09482.
@rustbot label: +llvm-main
|
|
Drop "gnu" in the target env for FreeBSD armv6/7
FreeBSD is not a GNU system
|
|
|
|
|
|
|
|
Clippy subtree update
r? `@Manishearth`
|
|
|
|
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
|
|
|
|
remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead
This brings us one step closer towards removing support for `extern "rust-intrinsic"` blocks, in favor of `#[rustc_intrinsic]` functions.
Also move `#[rustc_intrinsic]` under the `intrinsics` feature gate, to match the `extern "rust-intrinsic"` style.
|
|
|
|
FreeBSD is not a GNU system
|
|
functions instead
|
|
Rollup of 5 pull requests
Successful merges:
- #132161 ([StableMIR] A few fixes to pretty printing)
- #132389 (coverage: Simplify parts of coverage graph creation)
- #132452 (coverage: Extract safe FFI wrapper functions to `llvm_cov`)
- #132590 (Simplify FFI calls for `-Ztime-llvm-passes` and `-Zprint-codegen-stats`)
- #132738 (Initialize channel `Block`s directly on the heap)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Initialize channel `Block`s directly on the heap
The channel's `Block::new` was causing a stack overflow because it held
32 item slots, instantiated on the stack before moving to `Box::new`.
The 32x multiplier made modestly-large item sizes untenable.
That block is now initialized directly on the heap.
Fixes #102246
try-job: test-various
|
|
Simplify FFI calls for `-Ztime-llvm-passes` and `-Zprint-codegen-stats`
The existing code for these unstable LLVM-infodump flags was jumping through hoops to pass an allocated C string across the FFI boundary, when it's much simpler to just write to a `&RustString` instead.
|
|
coverage: Extract safe FFI wrapper functions to `llvm_cov`
This PR takes all of the inline `unsafe` calls in coverage codegen, and all the safe wrapper functions in `coverageinfo/mod.rs`, and moves them to a new `llvm_cov` submodule that is dedicated to safe FFI wrapper functions. This reduces the mixing of abstraction levels in the rest of coverage codegen.
As a follow-up, this PR also tidies up the names and signatures of several of the coverage FFI functions.
|
|
coverage: Simplify parts of coverage graph creation
This is a combination of three semi-related simplifications to how coverage graphs are created, grouped into one PR to avoid conflicts.
There are no observable changes to the output of any of the coverage tests.
|
|
[StableMIR] A few fixes to pretty printing
Improve identation, and a few other rvalue printing
try-job: x86_64-msvc
try-job: test-various
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #130586 (Set "symbol name" in raw-dylib import libraries to the decorated name)
- #131913 (Add `{ignore,needs}-{rustc,std}-debug-assertions` directive support)
- #132095 (Fix #131977 parens mangled in shared mut static lint suggestion)
- #132131 ([StableMIR] API to retrieve definitions from crates)
- #132639 (core: move intrinsics.rs into intrinsics folder)
- #132696 (Compile `test_num_f128` conditionally on `reliable_f128_math` config)
- #132737 (bootstrap: Print better message if lock pid isn't available)
- #132739 (Fix `librustdoc/scrape_examples.rs` formatting)
- #132740 (Update test for LLVM 20's new vector splat syntax)
- #132741 (Update mips64 data layout to match LLVM 20 change)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update mips64 data layout to match LLVM 20 change
LLVM changed the data layout in https://github.com/llvm/llvm-project/pull/112084
|
|
Update test for LLVM 20's new vector splat syntax
that was introduced in https://github.com/llvm/llvm-project/pull/112548
|
|
Fix `librustdoc/scrape_examples.rs` formatting
Still working on the intra-doc link feature. This time I encountered this file and it bothered me a bit so fixing formatting. :3
r? ````@notriddle````
|
|
bootstrap: Print better message if lock pid isn't available
Not actually sure why, but sometimes the PID isn't available so we print
```
WARNING: build directory locked by process , waiting for lock
```
This makes the message a bit nicer in this case
|
|
fortanix:raoul/rte-235-fix_fmodl_missing_symbol_issue, r=tgross35
Compile `test_num_f128` conditionally on `reliable_f128_math` config
With #132434 merged, our internal SGX CI started failing with:
```
05:27:34 = note: rust-lld: error: undefined symbol: fmodl
05:27:34 >>> referenced by arith.rs:617 (core/src/ops/arith.rs:617)
05:27:34 >>> /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/std-5d5f11eb008c9091.std.d8141acc61ab7ac8-cgu.10.rcgu.o:(std::num::test_num::h7dd9449f6c01fde8)
05:27:34 >>> did you mean: fmodf
05:27:34 >>> defined in: /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/libcompiler_builtins-0376f439a2ebf305.rlib(compiler_builtins-0376f439a2ebf305.compiler_builtins.c22db39d25d6f802-cgu.148.rcgu.o)
```
This originated from the `test_num_f128` test not having the required conditional compilation. This PR fixes that issue.
cc: ````@jethrogb,```` ````@workingjubilee````
|
|
core: move intrinsics.rs into intrinsics folder
This makes the rustbot notification we have set up for this folder in `triagebot.toml` actually work. Also IMO it makes more sense to have it all in one folder.
|
|
[StableMIR] API to retrieve definitions from crates
Add functions to retrieve function definitions and static items from all crates (local and external).
For external crates, we're still missing items from trait implementation and primitives.
r? ````@compiler-errors:```` Do you know what is the best way to retrieve the associated items for primitives and trait implementations for external crates? Thanks!
|
|
Fix #131977 parens mangled in shared mut static lint suggestion
Resolves #131977 for static mut references after discussion with
Esteban & Jieyou on [t-compiler/help](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/linting.20with.20parens.20in.20the.20HIR).
This doesn't do anything to change the underlying issue if there are other expressions that generate lint suggestions which need to be applied within parentheses.
|
