| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This might have made sense if the algorithm could use `searchWords`
to skip having to look at `searchIndex`, but since it always
does a substring check on both the stock word and the normalizedName,
it doesn't seem to help performance anyway.
|
|
Rollup of 3 pull requests
Successful merges:
- #118962 (Annotate some bugs)
- #118969 (coverage: Use `Waker::noop` in async tests)
- #118974 (Annotate panic! reasons during enum layout)
Failed merges:
- #111658 (Refactor pre-getopts command line argument handling)
- #117449 (Avoid silencing relevant follow-up errors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Annotate panic! reasons during enum layout
Add some reasons to the panics, and use more exhaustive matches.
Also see: #118955
|
|
coverage: Use `Waker::noop` in async tests
Inspired by #118948.
---
`@rustbot` label +A-code-coverage
|
|
Annotate some bugs
Gives a semi-helpful message to some `bug!()`/`unreachable!()`/`panic!()`. This also works around some other bugs/panics/etc that weren't needed, and also makes some of them into `span_bug!`s so they also have a useful span.
Note to reviewer: best to disable whitespace when comparing for some cases where indentation changed.
cc #118955
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #113091 (Don't merge cfg and doc(cfg) attributes for re-exports)
- #115660 (rustdoc: allow resizing the sidebar / hiding the top bar)
- #118863 (rustc_mir_build: Enforce `rustc::potential_query_instability` lint)
- #118909 (Some cleanup and improvement for invalid ref casting impl)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Some cleanup and improvement for invalid ref casting impl
This PR makes some cleanups and improvements to the `invalid_reference_casting` implementation in preparation for linting on new patterns, while reusing most of the logic.
r? `@est31` (feel free to re-assign)
|
|
r=michaelwoerister
rustc_mir_build: Enforce `rustc::potential_query_instability` lint
Stop allowing `rustc::potential_query_instability` on all of `rustc_mir_build` and instead allow it on a case-by-case basis if it is safe to do so. In this crate there was only one instance of the lint, and it was safe to allow.
Part of https://github.com/rust-lang/rust/issues/84447 which is E-help-wanted.
|
|
rustdoc: allow resizing the sidebar / hiding the top bar
Fixes #97306
Preview: http://notriddle.com/rustdoc-html-demo-4/sidebar-resize/std/index.html
## Summary
This feature adds:
1. A checkbox to the Settings popover to hide the persistent navigation bar (the sidebar on large viewports and the top bar on small ones).
2. On large viewports, it adds a resize handle to the persistent sidebar. Resizing it into nothing is equivalent to turning off the persistent navigation bar checkbox in Settings.
3. If the navigation bar is hidden, a toolbar button to the left of the search appears. Clicking it brings the navigation bar back.
## Motivation
While "mobile mode" is definitely a good default, it's not the only reason people have wanted to hide the sidebar:
* Some people use tiling window managers, and don't like rustdoc's current breakpoints. Changing the breakpoints might help with that, but there's no perfect solution, because there's a gap between "huge screen" and "smartphone" where reasonable people can disagree about whether it makes sense for the sidebar to be on-screen. https://github.com/rust-lang/rust/issues/97306
* Some people ask for ways to reduce on-screen clutter because it makes it easier to focus. There's not a media query for that (and if there was, privacy-conscious users would turn it off). https://github.com/rust-lang/rust/issues/59829
This feature is designed to avoid these problems. Resizing the sidebar especially helps, because it provides a way to hide the sidebar without adding a new top-level button (which would add clutter), and it provides a way to make rustdoc play nicer in complex, custom screen layouts.
## Guide and Reference-level explanation
On a desktop or laptop with a mouse, resize the sidebar by dragging its right edge.
On any browser, including mobile phones, the sticky top bar or side bar can be hidden from the Settings area (the button with the cog wheel, next to the search bar). When it's hidden, a convenient button will appear on the search bar's left.
## Drawbacks
This adds more JavaScript code to the render blocking area.
## Rationale and alternatives
The most obvious way to allow people to hide the sidebar would have been to let them "manually enter mobile mode." The upside is that it's a feature we already have. The downside is that it's actually really hard to come up with a terse description. Is it:
* A Setting that forces desktop viewers to always have the mobile-style top bar? If so, how do we label it? Should it be visible on mobile, and, if so, does it just not do anything?
* A persistent hide/show sidebar button, present on desktop, just like on mobile? That's clutter that I'd like to avoid.
## Prior art
* The new file browser in GitHub uses a similar divider with a mouse-over indicator
* mdBook and macOS Finder both allow you to resize the sidebar to nothing as a gesture to hide it
* https://www.nngroup.com/articles/drag-drop/
## Future possibilities
https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Table.20of.20contents proposes a new, second sidebar (a table of contents). How should it fit in with this feature? Should it be resizeable? Hideable? Can it be accessed on mobile?
|
|
Don't merge cfg and doc(cfg) attributes for re-exports
Fixes #112881.
## Explanations
When re-exporting things with different `cfg`s there are two things that can happen:
* The re-export uses a subset of `cfg`s, this subset is sufficient so that the item will appear exactly with the subset
* The re-export uses a non-subset of `cfg`s (e.g. like the example I posted just above where the re-export is ungated), if the non-subset `cfg`s are active (e.g. compiling that example on windows) then this will be a compile error as the item doesn't exist to re-export, if the subset `cfg`s are active it behaves like 1.
### Glob re-exports?
**This only applies to non-glob inlined re-exports.** For glob re-exports the item may or may not exist to be re-exported (potentially the `cfg`s on the path up until the glob can be removed, and only `cfg`s on the globbed item itself matter), for non-inlined re-exports see https://github.com/rust-lang/rust/issues/85043.
cc `@Nemo157`
r? `@notriddle`
|
|
rustdoc-search: fix a race condition in search index loading
`var` declare it in the global scope, and `const` does not. It needs to be declared in global scope.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const
> const declarations do not create properties on [globalThis](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis) when declared at the top level of a script.
Fixes a regression introduced by https://github.com/rust-lang/rust/pull/118910
|
|
Add some reasons to the panics, and use more exhaustive matches.
|
|
Rollup of 2 pull requests
Successful merges:
- #118927 (Erase late bound regions from `Instance::fn_sig()` and add a few more details to StableMIR APIs)
- #118964 (Opportunistically resolve region var in canonicalizer (instead of resolving root var))
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Opportunistically resolve region var in canonicalizer (instead of resolving root var)
See comment in `compiler/rustc_type_ir/src/infcx.rs`.
The **root** infer region for a given region vid may not actually be nameable from the universe of the original vid. That means that the assertion in the canonicalizer was too strict, since the `EagerResolver` that we use before canonicalizing is doing only as much resolving as it can.
This replaces `resolve_lt_var` and `probe_lt_var` in the `rustc_type_ir` API with `opportunistic_resolve_lt_var`, which acts as you expect it should. I left a FIXME that complains about the inconsistency.
This test is really gnarly, but I have no idea how to minimize it, since it seems to kind of just be coincidental that it triggered this issue. I hope the underlying root cause is easy enough to understand, though.
r? `@lcnr` or `@aliemjay`
Fixes #118950
|
|
Erase late bound regions from `Instance::fn_sig()` and add a few more details to StableMIR APIs
The Instance `fn_sig()` still included a late bound regions which needed a new compiler function in order to be erased. I've also bundled the following small fixes in this PR, let me know if you want me to isolate any of them.
- Add missing `CoroutineKind::AsyncGen`.
- Add optional spread argument to function body which is needed to properly analyze compiler shims.
- Add a utility method to iterate over all locals together with their declaration.
- Add a method to get the description of `AssertMessage`*.
* For the last one, we could consider eventually calling the internal `AssertKind::description()` to avoid code duplication. However, we still don't have ways to convert `AssertMessage`, `Operand`, `Place` and others, in order to use that. The other downside of using the internal method is that it will panic for some of the variants.
r ? `@ouz-a`
|
|
Rollup of 3 pull requests
Successful merges:
- #116888 (Add discussion that concurrent access to the environment is unsafe)
- #118888 (Uplift `TypeAndMut` and `ClosureKind` to `rustc_type_ir`)
- #118929 (coverage: Tidy up early parts of the instrumentor pass)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
coverage: Tidy up early parts of the instrumentor pass
This is extracted from #118237, which needed to be manually rebased anyway.
Unlike that PR, this one only affects the coverage instrumentor, and doesn't attempt to move any code into the MIR builder. That can be left to a future version of #118305, which can still benefit from these improvements.
So this is now mostly a refactoring of some internal parts of the instrumentor.
|
|
Uplift `TypeAndMut` and `ClosureKind` to `rustc_type_ir`
Uplifts `TypeAndMut` and `ClosureKind`
I know I said I was just going to get rid of `TypeAndMut` (https://github.com/rust-lang/types-team/issues/124) but I think this is much simpler, lol
r? `@jackh726` or `@lcnr`
|
|
Add discussion that concurrent access to the environment is unsafe
The bug report #27970 has existed for 8 years, the actual bug dates back to Rust pre-1.0. I documented it since it's in the interest of the user to be aware of it. The note can be removed once #27970 is fixed.
|
|
|
|
Fix cases where std accidentally relied on inline(never)
This PR increases the power of `-Zcross-crate-inline-threshold=always` so that it applies through `#[inline(never)]`. Note that though this is called "cross-crate-inlining" in this case especially it is _just_ lazy per-CGU codegen. The MIR inliner and LLVM still respect the attribute as much as they ever have.
Trying to bootstrap with the new `-Zcross-crate-inline-threshold=always` change revealed two bugs:
We have special intrinsics `assert_inhabited`, `assert_zero_valid`, and `assert_mem_uniniitalized_valid` which codegen backends will lower to nothing or a call to `panic_nounwind`. Since we may not have any call to `panic_nounwind` in MIR but emit one anyway, we need to specially tell `MirUsedCollector` about this situation.
`#[lang = "start"]` is special-cased already so that `MirUsedCollector` will collect it, but then when we make it cross-crate-inlinable it is only assigned to a CGU based on whether `MirUsedCollector` saw a call to it, which of course we didn't.
---
I started looking into this because https://github.com/rust-lang/rust/pull/118683 revealed a case where we were accidentally relying on a function being `#[inline(never)]`, and cranking up cross-crate-inlinability seems like a way to find other situations like that.
r? `@nnethercote` because I don't like what I'm doing to the CGU partitioning code here but I can't come up with something much better
|
|
`var` declare it in the global scope, and `const` does not.
It needs to be declared in global scope.
|
|
Update to LLVM 17.0.6
This is a rebase on the final LLVM 17 release.
Includes the RISCV fix requested in https://github.com/rust-lang/llvm-project/pull/157 (and I think this is also the only change in this release that is relevant to rustc).
r? `@cuviper`
Fixes #117902
|
|
- Remove `fn_sig()` from Instance.
- Change return value of `AssertMessage::description` to `Cow<>`.
- Add assert to instance `ty()`.
- Generalize uint / int type creation.
|
|
Rollup of 4 pull requests
Successful merges:
- #118908 (Add all known `target_feature` configs to check-cfg)
- #118933 (Cleanup errors handlers even more)
- #118943 (update `measureme` to 10.1.2 to deduplicate `parking_lot`)
- #118948 (Use the `Waker::noop` API in tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use the `Waker::noop` API in tests
Avoids the need to duplicate this code over and over again
r? eholk
|
|
update `measureme` to 10.1.2 to deduplicate `parking_lot`
This PR updates `measureme` to the latest release to remove the last duplicates of `parking_lot` 0.11 we had in our dependency tree.
```console
Updating measureme v10.1.1 -> v10.1.2
Removing parking_lot v0.11.2
Removing parking_lot_core v0.8.6
```
Also removes `instant` from the allowed list of dependencies, as it's no longer used.
r? `@michaelwoerister` (Thanks for the release in the first place 🙏)
|
|
r=compiler-errors
Cleanup errors handlers even more
A sequel to #118587.
r? `@compiler-errors`
|
|
r=TaKO8Ki,GuillaumeGomez,workingjubilee
Add all known `target_feature` configs to check-cfg
This PR adds all the known `target_feature` from ~~`rustc_codegen_ssa`~~ `rustc_target` to the well known list of check-cfg.
It does so by moving the list from `rustc_codegen_ssa` to `rustc_target` ~~`rustc_session` (I not sure about this, but some of the moved function take a `Session`)~~, then using it the `fill_well_known` function.
This already proved to be useful since portable-simd had a bad cfg.
cc `@nnethercote` (since we discussed it in https://github.com/rust-lang/rust/pull/118494)
|
|
This will normally be true, but in cases where it's not true we're better off
not making any assumptions about the signature.
|
|
If we want to know whether two byte positions are in the same file, we don't
need to clone and compare `Lrc<SourceFile>`; we can just get their indices and
compare those instead.
|
|
|
|
|
|
|
|
We can just as easily look it up again from the source map and body span when
needed.
|
|
|
|
Changes in this patch:
- Extract local variable `def_id`
- Check `is_fn_like` without retrieving HIR
- Inline some locals that are used once and aren't needed for clarity
|
|
|
|
Currently, `emit_diagnostic` takes `&mut self`.
This commit changes it so `emit_diagnostic` takes `self` and the new
`emit_diagnostic_without_consuming` function takes `&mut self`.
I find the distinction useful. The former case is much more common, and
avoids a bunch of `mut` and `&mut` occurrences. We can also restrict the
latter with `pub(crate)` which is nice.
|
|
Compare `Handler::warn` and `Handler::span_warn`. Conceptually they are
almost identical. But their implementations are weirdly different.
`warn`:
- calls `DiagnosticBuilder::<()>::new(self, Warning(None), msg)`, then `emit()`
- which calls `G::diagnostic_builder_emit_producing_guarantee(self)`
- which calls `handler.emit_diagnostic(&mut db.inner.diagnostic)`
`span_warn`:
- calls `self.emit_diag_at_span(Diagnostic::new(Warning(None), msg), span)`
- which calls `self.emit_diagnostic(diag.set_span(sp))`
I.e. they both end up at `emit_diagnostic`, but take very different
routes to get there.
This commit changes `span_*` and similar ones to not use
`emit_diag_at_span`. Instead they just call `struct_span_*` + `emit`.
Some nice side-effects of this:
- `span_fatal` and `span_fatal_with_code` don't need
`FatalError.raise()`, because `emit` does that.
- `span_err` and `span_err_with_code` doesn't need `unwrap`.
- `struct_span_note`'s `span` arg type is changed from `Span` to
`impl Into<MultiSpan>` like all the other functions.
|
|
The `Handler` functions that directly emit diagnostics can be more
easily implemented using `struct_foo(msg).emit()`. This mirrors
`Handler::emit_err` which just does `create_err(err).emit()`.
`Handler::bug` is not converted because of weirdness involving
conflation bugs and fatal errors with `EmissionGuarantee`. I'll fix that
later.
|
|
To `msg: impl Into<DiagnosticMessage>`, like all the other diagnostics.
For consistency.
|
|
Rollup of 4 pull requests
Successful merges:
- #118910 ([rustdoc] Use Map instead of Object for source files and search index)
- #118914 (Unconditionally register alias-relate in projection goal)
- #118935 (interpret: extend comment on the inhabitedness check in downcast)
- #118945 (rustc_codegen_ssa: Remove trailing spaces in Display impl for CguReuse)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustc_codegen_ssa: Remove trailing spaces in Display impl for CguReuse
Otherwise errors will look like this:
error: CGU-reuse for `cgu_invalidated_via_import-bar` is `PreLto ` but should be `PostLto `
### Background
I noticed that error messages looked wonky while investigating if
https://github.com/rust-lang/rust/blob/529047cfc3f4f7b3ea5aaac054408f368d153727/compiler/rustc_codegen_ssa/src/assert_module_sources.rs#L281-L287
should not be wrapped by `sess.emit_err(...)`. Right now it looks like the error is accidentally ignored. It looks like https://github.com/rust-lang/rust/pull/100753/commits/706452eba74026c51e8d0fa30aee2497c69eafc0 might have accidentally started ignoring it (by removing the `diag.span_err()` call). I am still investigating, but regardless of the outcome we should fix the trailing whitespace.
|
|
interpret: extend comment on the inhabitedness check in downcast
Cc https://github.com/rust-lang/rust/issues/115145
r? ``@saethlin``
|
|
Unconditionally register alias-relate in projection goal
Follow-up to #118725, which subtly broke closure signature inference on combinators like `Result::map` which I noticed in syn.
Essentially, instead of using `eq` which will eagerly infer `?1 := <?2 as Trait>::Assoc`, we can directly emit an alias-relate goal, which will stay ambiguous for as long as `?2` is ambiguous.
This also more closely models the conceptual framing that projects-to acts like an alias-relate when solving, and like a normalizes-to when in a param env.
r? lcnr
|
