| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 9 pull requests
Successful merges:
- #121560 (Allow `#[deny]` inside `#[forbid]` as a no-op)
- #131365 (Fix missing rustfmt in msi installer #101993)
- #131647 (Register `src/tools/unicode-table-generator` as a runnable tool)
- #131843 (compiler: Error on layout of enums with invalid reprs)
- #131926 (Align boolean option descriptions in `configure.py`)
- #131961 (compiletest: tidy up how `tidy` and `tidy` (html version) are disambiguated)
- #131962 (Make `llvm::set_section` take a `&CStr`)
- #131964 (add latest crash tests)
- #131965 (remove outdated comment)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
remove outdated comment
https://github.com/rust-lang/rust/issues/44234 was closed, apparently solved by https://github.com/rust-lang/rust/pull/45353
|
|
add latest crash tests
r? `@jieyouxu`
|
|
Make `llvm::set_section` take a `&CStr`
There's no reason to convert the section name to an intermediate `String`, when the LLVM-C API wants a C string anyway.
Follow-up to #131876.
|
|
compiletest: tidy up how `tidy` and `tidy` (html version) are disambiguated
Rename `has_tidy` -> `has_html_tidy` (`tidy` is also a bootstrap tool, but rustdoc uses a html tidy that has the same binary name). Follow-up to #131941.
Also apparently `runtest.rs` is short enough now, we can delete the `tidy` (bootstrap version) ignore for file length.
|
|
Align boolean option descriptions in `configure.py`
Boolean options are currently printed as
```
Options
--enable-debug OR --disable-debug enables debugging environment; does not affect optimization of bootstrapped code
--enable-docs OR --disable-docs build standard library documentation
--enable-compiler-docs OR --disable-compiler-docs build compiler documentation
--enable-optimize-tests OR --disable-optimize-tests build tests with optimizations
--enable-verbose-tests OR --disable-verbose-tests enable verbose output when running tests
--enable-ccache OR --disable-ccache invoke gcc/clang via ccache to reuse object files between builds
--enable-sccache OR --disable-sccache invoke gcc/clang via sccache to reuse object files between builds
--enable-local-rust OR --disable-local-rust use an installed rustc rather than downloading a snapshot
--local-rust-root=VAL set prefix for local rust binary
--enable-local-rebuild OR --disable-local-rebuild assume local-rust matches the current version, for rebuilds; implies local-rust, and is implied if local-rust already matches the current version
```
as of #131117
imo, this is a little difficult to skim. This PR changes this to align the `OR`s and push the description onto a newline:
```
Options
--enable-debug OR --disable-debug
enables debugging environment; does not affect optimization of bootstrapped code
--enable-docs OR --disable-docs
build standard library documentation
--enable-compiler-docs OR --disable-compiler-docs
build compiler documentation
--enable-optimize-tests OR --disable-optimize-tests
build tests with optimizations
--enable-verbose-tests OR --disable-verbose-tests
enable verbose output when running tests
--enable-ccache OR --disable-ccache
invoke gcc/clang via ccache to reuse object files between builds
--enable-sccache OR --disable-sccache
invoke gcc/clang via sccache to reuse object files between builds
--enable-local-rust OR --disable-local-rust
use an installed rustc rather than downloading a snapshot
--local-rust-root=VAL set prefix for local rust binary
--enable-local-rebuild OR --disable-local-rebuild
assume local-rust matches the current version, for rebuilds; implies local-rust, and is implied if local-rust already matches the current version
```
|
|
compiler: Error on layout of enums with invalid reprs
Surprising no one, the ICEs with the same message have the same root cause.
Invalid reprs can reach layout computation for various reasons. For instance, the compiler may want to use its layout computations to discern if a combination of layout-affecting attributes results in a valid type to begin with by e.g. computing its size. When the input is bad, return an error reflecting that the answer to the question is not a useful one.
|
|
Register `src/tools/unicode-table-generator` as a runnable tool
It seems like `src/tools/unicode-table-generator` is not currently managed by bootstrap. This PR wires it up with bootstrap as a runnable tool.
This tool seems to take two possible args:
1. (Mandatory) path to `library/core/src/unicode/unicode_data.rs`, and
2. (Optional) path to generate a test file.
I only passed the mandatory path to `unicode_data.rs` in bootstrap and didn't do anything about (2). I'm not sure about how this tool is supposed to be run.
`Cargo.lock` is modified because I renamed `unicode-table-generator`'s bin name to match the tool name, as bootstrap's tool running logic expects the bin name to be derived from the tool name.
I also added a triagebot message to remind to not manually edit the library source file and edit the tool then regenerate instead, but this should probably be a tidy check (if that's desirable then that can be in a follow-up PR, though may be overkill).
Helps with #131640 but does not close it because still no docs.
r? `@Mark-Simulacrum` (since I think you authored this tool?)
|
|
Fix missing rustfmt in msi installer #101993
# Context
- Fixed missing `rustfmt`, `clippy`, `miri` and `rust-analyzer` in msi installer
- Fixed missing `rustfmt` for apple darwin installer
- Closes #101993
r? `@jyn514`
- Please let me know if I should request from someone else instead. I divided the changes into 3 separate commits for the ease of review. The refactoring commit `fbdfd5c03c3c979bcf105ccdd05ff4ab9f37a763` is a bit more involved, but I think it helps in the long term for readability and to avoid bugs.
- I changed `build-manifest` to `build_manifest` in order to invoke it as a library. Not sure if this is gonna break any upstream processes. I checked `generate-manifest-list` and `generate-release` but didn't find any obvious reference
- Will push fixes for linting later
|
|
Allow `#[deny]` inside `#[forbid]` as a no-op
Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense.
Except it doesn't, because macros. Macros may reasonably use `#[deny]` (or `#[warn]` for an allow-by-default lint) in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint!
By making it a warning instead, we remove the problem with the macro, which is now nothing as warnings are suppressed in macro expanded code, while still telling users that something is up.
fixes #121483
|
|
|
|
|
|
#44234 is resolved
|
|
|
|
|
|
|
|
Remove unused `recoverable` argument in collect_intra_doc_links
r? `@notriddle`
|
|
Rollup of 4 pull requests
Successful merges:
- #131876 (compiler: Use LLVM's Comdat support)
- #131941 (compiletest: disambiguate html-tidy from rust tidy tool)
- #131942 (compiler: Adopt rust-analyzer impls for `LayoutCalculatorError`)
- #131945 (rustdoc: Clean up footnote handling)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: Clean up footnote handling
Best reviewed commit by commit.
Extracts footnote handling logic into it's own file (first commit) and then makes that file slightly nicer to read/understand.
No functional changes, but lays the groundwork for making more changes to footnotes (eg #131901, #131946)
|
|
compiler: Adopt rust-analyzer impls for `LayoutCalculatorError`
We're about to massively churn the internals of `rustc_abi`. To minimize the immediate and future impact on rust-analyzer, as a subtree that depends on this crate, grow some API on `LayoutCalculatorError` that reflects their uses of it. This way we can nest the type in theirs, and they can just call functions on it without having to inspect and flatten-out its innards.
|
|
compiletest: disambiguate html-tidy from rust tidy tool
when i first saw this error message i was very confused, i thought it was talking about `src/tools/tidy`. now it should be much more clear what tool should be installed.
|
|
compiler: Use LLVM's Comdat support
Acting on these long-ago issues:
- https://github.com/rust-lang/rust/issues/46437
- https://github.com/rust-lang/rust/issues/68955
|
|
|
|
refactor fudge_inference, handle effect vars
this makes it easier to use fudging outside of `fudge_inference_if_ok`, which is likely necessary to handle inference variable leaks on rollback.
We now also uses exhaustive matches where possible and improve the code to handle effect vars.
r? `@compiler-errors` `@BoxyUwU`
|
|
Rollup of 12 pull requests
Successful merges:
- #116863 (warn less about non-exhaustive in ffi)
- #127675 (Remove invalid help diagnostics for const pointer)
- #131772 (Remove `const_refs_to_static` TODO in proc_macro)
- #131789 (Make sure that outer opaques capture inner opaques's lifetimes even with precise capturing syntax)
- #131795 (Stop inverting expectation in normalization errors)
- #131920 (Add codegen test for branchy bool match)
- #131921 (replace STATX_ALL with (STATX_BASIC_STATS | STATX_BTIME) as former is deprecated)
- #131925 (Warn on redundant `--cfg` directive when revisions are used)
- #131931 (Remove unnecessary constness from `lower_generic_args_of_path`)
- #131932 (use tracked_path in rustc_fluent_macro)
- #131936 (feat(rustdoc-json-types): introduce rustc-hash feature)
- #131939 (Get rid of `OnlySelfBounds`)
Failed merges:
- #131181 (Compiletest: Custom differ)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Get rid of `OnlySelfBounds`
We turn `PredicateFilter` into a newtyped bool called `OnlySelfBounds`. There's no reason to lose the information of the `PredicateFilter`, so let's just pass it all the way through.
|
|
feat(rustdoc-json-types): introduce rustc-hash feature
This allows the public `rustdoc-types` crate to expose this feature easily and allows consumers of the crate to get the performance advantages from doing so.
The reasoning for this was discussed on [Zulip][1]
Changes:
- Make `rustc-hash` optional but default to including it
- Rename all occurrences of `FxHashMap` to `HashMap`.
- Feature gate the import and rename the imported `FxHashMap` to `HashMap`
- Introduce a type alias `FxHashMap` which resolves to the currently used `HashMap` (`rustc_hash::FxHashMap` or `std::collections::HashMap`) for use in `src/librustdoc`.
[1]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/rustc-hash.20and.20performance.20of.20rustdoc-types
**extra context from the zulip thread:**
- `@obi1kenobi` requested benchmarks of the switch to `rustc-hash`
- I benchmarked switching `rustdoc-types` to `rustc-hash` which yielded a ~300ms improvement to `cargo-semver-checks`'s index building step (this step is done twice so the improvements are ~150ms per index).
- The benchmarks were presented in Zulip and people were in favor of introducing `rustc-hash` to the public `rustdoc-types` crate.
- There were differing opinions on how to introduce the dependency:
1. "Hard" dependency: remove use of `std::collections::HashMap` in favor of `FxHashMap`.
2. "Soft" dependency: make optional and introduce a feature then enable/disable it by default (this PR).
3. ~~Make `rustdoc-types` generic and expose the `RandomState`~~ (a lot of work & complexity for little gain over a feature gate).
`@obi1kenobi` and I prefer the feature gate so that is what I am adding here.
My reasons for the preference are:
- `cargo-semver-checks` is especially perf sensitive, we don't expect people to care about ~150ms extra time when reading in a 500MB file (the size of the sample we used for benchmarking).
- Keeping `rustdoc-types` lean by having its only direct dependency be `serde` is nice for the general consumer of the crate.
- `rustc-hash` is not HashDOS resistant (but it is questionable whether `rustdoc-types` would be used on adversarial inputs).
r? `@aDotInTheVoid`
|
|
use tracked_path in rustc_fluent_macro
According to comments in https://github.com/rust-lang/rust/issues/99515#issuecomment-2135003881, the trick used in `rustc_fluent_macro` may be broken by caching decl macros. So use `proc_macro::tracked_path::path` to ensure it works.
|
|
Remove unnecessary constness from `lower_generic_args_of_path`
We pass `NotConst` to all callsites of `lower_generic_args_of_path` except for `lower_poly_trait_ref`, so let's not do that.
|
|
Warn on redundant `--cfg` directive when revisions are used
r? ``@jieyouxu``
Fixes #131390
Not sure of the best way to test this
|
|
replace STATX_ALL with (STATX_BASIC_STATS | STATX_BTIME) as former is deprecated
STATX_ALL was deprecated in https://github.com/torvalds/linux/commit/581701b7efd60ba13d8a7eed60cbdd7fefaf6696 and suggested to use equivalent (STATX_BASIC_STATS | STATX_BTIME) combination, to prevent future surprises.
|
|
Add codegen test for branchy bool match
Closes #108395
|
|
Stop inverting expectation in normalization errors
We have some funky special case logic to invert the expectation and actual type for normalization errors depending on their cause code. IMO most of the error messages get better, except for `try {}` blocks' type expectations. I think that these need to be special cased in some other way, rather than via this hack.
Fixes #131763
|
|
Make sure that outer opaques capture inner opaques's lifetimes even with precise capturing syntax
When lowering an opaque, we must capture and duplicate all of the lifetimes in the opaque's bounds to correctly lower the opaque's bounds. We do this *even if* the lifetime is not captured according to the `+ use<>` precise capturing bound; in that case, we will later reject that captured lifetime. For example, Given an opaque like `impl Sized + 'a + use<>`, we will still duplicate `'a` but later error that it is not mentioned in the `use<>` bound.
The current heuristic was not properly handling cases like:
```
//@ edition: 2024
fn foo<'a>() -> impl Trait<Assoc = impl Trait2> + use<> {}
```
Which forces the outer `impl Trait` to capture `'a` since `impl Trait2` *implicitly* captures `'a` due to the new lifetime capture rules for edition 2024. We were only capturing lifetimes syntactically mentioned in the bounds. (Note that this still is an error; we just need to capture `'a` so it is handled later in the compiler correctly -- hence the ICE in #131769 where a late-bound lifetime was being referenced outside of its binder).
This PR reworks the way we collect lifetimes to capture and duplicate in AST lowering to fix this.
Fixes #131769
|
|
Remove `const_refs_to_static` TODO in proc_macro
Noticed this TODO, and with `const_refs_to_static` being stable now we can sort it out.
|
|
Remove invalid help diagnostics for const pointer
Partially addresses #127562
|
|
r=jieyouxu
warn less about non-exhaustive in ffi
Bindgen allows generating `#[non_exhaustive] #[repr(u32)]` enums. This results in nonintuitive nonlocal `improper_ctypes` warnings, even when the types are otherwise perfectly valid in C.
Adjust for actual tooling expectations by avoiding warning on simple enums with only unit variants.
Closes https://github.com/rust-lang/rust/issues/116831
|
|
Update `compiler-builtins` to 0.1.134
I'm modeling this PR after https://github.com/rust-lang/rust/pull/131314.
This pulls in https://github.com/rust-lang/compiler-builtins/pull/713 which should mitigate the problem reported and discussed in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Hello.20World.20on.20sparc-unknown-none-elf.20crashes
|
|
|
|
|
|
|
|
|
|
precise capturing syntax
|
|
|
|
|
|
Migrate `llvm::set_comdat` and `llvm::SetUniqueComdat` to LLVM-C FFI.
Note, now we can call `llvm::set_comdat` only when the target actually
supports adding comdat. As this has no convenient LLVM-C API, we
implement this as `TargetOptions::supports_comdat`.
Co-authored-by: Stuart Cook <Zalathar@users.noreply.github.com>
|
|
Rollup of 8 pull requests
Successful merges:
- #127462 (std: uefi: Add basic Env variables)
- #131537 (Fix range misleading field access)
- #131838 (bootstrap: allow setting `--jobs` in config.toml)
- #131890 (Update `use` keyword docs to describe precise capturing)
- #131899 (Mark unexpected variant res suggestion as having placeholders)
- #131908 (rustdoc: Switch from FxHash to sha256 for static file hashing.)
- #131916 (small interpreter error cleanup)
- #131919 (zero-sized accesses are fine on null pointers)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This allows the public `rustdoc-types` crate to expose this feature
easily and allows consumers of the crate to get the performance
advantages from doing so.
The reasoning for this was discussed on [Zulip][1]
Changes:
- Make `rustc-hash` optional but default to including it
- Rename all occurrences of `FxHashMap` to `HashMap`.
- Feature gate the import and rename the imported `FxHashMap` to
`HashMap`
- Introduce a type alias `FxHashMap` which resolves to the currently
used `HashMap` (`rustc_hash::FxHashMap` or
`std::collections::HashMap`) for use in `src/librustdoc`.
[1]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/rustc-hash.20and.20performance.20of.20rustdoc-types
|
|
|
|
zero-sized accesses are fine on null pointers
We entirely forgot to update all the function docs when changing the central docs. That's the problem with helpfully repeating shared definitions in tons of places...
|
