"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."
In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)
This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.
This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
FYI: `@wesleywiser`
r? `@tmandry`
LLVMWrapper: attractive nuisance macros
This came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.
small cleanups in rustc_errors / emitter
This is either moving code around so it gets called less often or using if let instead of match in a few cases.
Add Result::into_err where the Ok variant is the never type
Equivalent of #66045 but for the inverse situation where `T: Into<!>` rather than `E: Into<!>`.
I'm using the same feature gate name. I can't see why one of these methods would be OK to stabilize but not the other.
Tracking issue: #61695
Add documentation for rustdoc-gui tests
I think a bit of documentation doesn't hurt in this case considering how "out of the ordinary" this is.
r? ``@jyn514``
Remove Option::{unwrap_none, expect_none}.
This removes `Option::unwrap_none` and `Option::expect_none` since we're not going to stabilize them, see https://github.com/rust-lang/rust/issues/62633.
Closes#62633
stabilize debug_non_exhaustive
tracking issue: https://github.com/rust-lang/rust/issues/67364
but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate, as this one seems uncontroversial enough to stabilize as is
Use `EvaluatedToOkModuloRegions` whenever we erase regions
Fixes#80691
When we evaluate a trait predicate, we convert an
`EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any
regions. We cache the result under a region-erased 'freshened'
predicate, so `EvaluatedToOk` may not be correct for other predicates
that have the same cache key.
Fixes#80691
When we evaluate a trait predicate, we convert an
`EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any
regions. We cache the result under a region-erased 'freshened'
predicate, so `EvaluatedToOk` may not be correct for other predicates
that have the same cache key.
THis came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.
2229 migration: Don't try resolve regions before writeback
In the analysis use `resolve_vars_if_possible` instead of `fully_resolve`,
because we might not have performed regionck yet.
Fixes: #83176
r? `@nikomatsakis`
Expose str::SplitInclusive in alloc and therefore in std
This seems to have been omitted from the beginning when this feature was first introduced in 86bf96291d. Most users won't need to name this type which is probably why this wasn't noticed in the meantime.
See #83372 for a different but related bug.
### Notes for reviewers
I think I have got this right but TBH I am not very familiar with the relationship between core and std and so on. <strike>I also haven't don't any kind of test (not even a build) yet. I will do a local docs build to see that the type now appears in the std docs.</strike> I did a local docs build and it has made this type appear as `std::str::SplitInclusive` as expected
The linkification of the return value from `str::split_inclusive` teleports me to the online url for `core::str::SplitInclusive`. I think this may be a rustdoc anomaly (similar to #79630 maybe) but I am not sure. Perhaps it means I haven't done the `std` -> `core` referrence correctly.
I made this insta-stable since it seems like simply a bug. Please LMK if that is not right. *(edited to add:)* In particular, IDK how this ought to relate to the (?)current release process.
implement `feature(const_generics_defaults)`
Implements const generics defaults `struct Example<const N: usize=3>`, as well as a query for getting the default of a given const-parameter's def id. There are some remaining FIXME's but they were specified as not blocking for merging this PR. This also puts the defaults behind the unstable feature gate `#![feature(const_generics_defaults)]`.
~~This currently creates a field which is always false on `GenericParamDefKind` for future use when
consts are permitted to have defaults. I'm not sure if this is exactly what is best for adding default parameters, but I mimicked the style of type defaults, so hopefully this is ok.~~
r? `@lcnr`
Remove unnecessary `Option` wrapping around `Crate.module`
I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.
Slight visual improvements to warning boxes in the docs
First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility).
For consistency the microscope has the black border too.
Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either.
Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum.
But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue.
I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that.
I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum:
Blue = friendly, "use it".
Red = danger, "don't use it".
And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits.
However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes.
This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes:
Change `-W help` to display edition level.
`-W help` was not honoring the `--edition` flag when displaying the default lint level. It was using the edition for sorting, but not for the final display.
This isn't important right now as there aren't any edition-specific lint levels. Also, the `declare_lint` macro is broken and doesn't even allow setting them right now. However, I figure it wouldn't hurt to fix this before I forget about it, in case edition-specific lints are ever used in the future.
Allow not emitting `uwtable` on Android
`uwtable` is marked as required on Android, so it can't be disabled via `-C force-unwind-tables=no`. However, I found that the reason it's marked as required was to resolve a [backtrace issue in Gecko](https://github.com/rust-lang/rust/issues/49867), and I haven't find any other reasons that make it required ([yet](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Unwind.20tables.20are.20strictly.20required.20on.20Windows.20and.20Android)). Therefore, I assume it's safe to turn it off if a (nice) backtrace is not needed, and submit this PR to allow `-C force-unwind-tables=no` when targeting Android.
Note that I haven't tested this change on Android as I don't have an Android environment for testing.
Add internal io::Error::new_const to avoid allocations.
This makes it possible to have a io::Error containing a message with zero allocations, and uses that everywhere to avoid the *three* allocations involved in `io::Error::new(kind, "message")`.
The function signature isn't perfect, because it needs a reference to the `&str`. So for now, this is just a `pub(crate)` function. Later, we'll be able to use `fn new_const<MSG: &'static str>(kind: ErrorKind)` to make that a bit better. (Then we'll also be able to use some ZST trickery if that would result in more efficient code.)
See https://github.com/rust-lang/rust/issues/83352
Only enable assert_dep_graph when query-dep-graph is enabled.
This is a debugging option. The only effect should be on rustc tests.
r? ``@michaelwoerister``
Sidebar trait items order
We were actually sorting `Symbol` and not `String`, creating a completely invalid sort result. I added a test to prevent regressions.
r? ``@jyn514``
Rename `source` to `span` and `span` to `source`
- Rename `clean::Item.source` to `span`
- Rename `clean::Span::span()` to `clean::Span::inner()`
- Rename `rustdoc_json_types::Item.source` to `span`
- rustdoc-json: Rename `Import.span` to `Import.source`
*See also the [discussion on Zulip][z] (this is a bit more than discussed in
that conversation, but all the changes are related).*
r? `@jyn514`
[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/get.20span.20of.20file.20from.20name/near/229603729
I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.
