Revert #71956
...since it caused unsoundness in #73137. Also adds a reduced version of #73137 to the test suite. The addition of the `MaybeInitializedLocals` dataflow analysis has not been reverted, but it is no longer used.
Presumably there is a more targeted fix, but I'm worried that other bugs may be lurking. I'm not yet sure what the root cause of #73137 is.
This will need to get backported to beta.
r? @tmandry
Free `default()` forwarding to `Default::default()`
It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance.
Especially so, compared to Haskell, where the same functionality is called `def`.
Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation.
The trait is still there, so if someone wants to be explicit and to say `Default::default()` - it still works, but if imported as `std::default::default;`, then the free function reduces typing and visual noise.
Add `-Z span-debug` to allow for easier debugging of proc macros
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once #72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
Update annotate-snippets-rs to 0.8.0
#59346
I made major changes to this library. In the previous version we worked with owned while in the current one with borrowed.
I have adapted it without changing the behavior.
I have modified the coverage since the previous one did not return correctly the index of the character in the line.
When creating default values a trait method needs to be called with an
explicit trait name. `Default::default()` seems redundant. A free
function on the other hand, when imported directly, seems to be a better
API, as it is just `default()`. When implementing the trait, a method
is still required.
resolve: Sort E0408 errors by Symbol str
This is a request for comments implementing my suggested solution to https://github.com/rust-lang/rust/issues/72913
Previously errors were sorted by Symbol index instead of the string. The indexes are not the same between architectures because Symbols for architecture extensions (e.g. x86 AVX or RISC-V d) are interned before the source file is parsed. RISC-V's naming of extensions after single letters led to it having errors sorted differently for test cases using single letter variable names. Instead sort the errors by the Symbol string so that it is stable across architectures.
While I was at it, there's also 8edb05c2 skipping some ui tests which I think are irrelevant for risc-v.
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once #72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
Previously errors were sorted by Symbol index instead of the string. The
indexes are not the same between architectures because Symbols for
architecture extensions (e.g. x86 AVX or RISC-V d) are interned before
the source file is parsed. RISC-V's naming of extensions after single
letters led to it having errors sorted differently for test cases using
single letter variable names. Instead sort the errors by the Symbol
string so that it is stable across architectures.
Don't count pathless --extern for unused-crate-dependencies warnings
`--extern proc_macro` is used to add the proc_macro crate to the extern
prelude for all procmacros. In general pathless `--extern` only references
sysroot/standard libraries and so should be exempt from
unused-crate-dependencies warnings.
r? @petrochenkov
WF-check all ty::Const's, not just array lengths.
fixes#68977
This PR removes the special case for array length in `wf::compute` and
checks the well formedness of all consts.
Changes `PredicateKind::WellFormed` to take a `GenericArg` and updates `wf::obligations`.
Add a test to ensure Fuse stays covariant
When #70502 attempted to specialize the data types in `Fuse`, one of the problems we found was that it broke variance. This was also realized when `Fuse` was first added, https://github.com/rust-lang/rust/pull/35656#discussion-diff-74995079, but now this PR adds a test so we don't forget again.
test miri-unleash TLS accesses
Finally gets rid of `IS_SUPPORTED_IN_MIRI`. :-)
I also added a test for the new `asm!` while I am at it.
r? @ecstatic-morse Cc @rust-lang/wg-const-eval
`--extern proc_macro` is used to add the proc_macro crate to the extern
prelude for all procmacros. In general pathless `--extern` only references
sysroot/standard libraries and so should be exempt from
unused-crate-dependencies warnings.
Add descriptions for all queries
This also removes the default description for queries with DefId keys and makes the macro validate that a description is provided.
cc #72730
r? @eddyb
Avoid setting wrong obligation cause span of associated type mismatch
Removes code that sets wrong obligation cause span of associated type mismatch. See the linked issue for details.
Closes#72806.
miri validation: clarify valid values of 'char'
The old text said "expected a valid unicode codepoint", which is not actually correct -- it has to be a scalar value (which is a code point that is not part of a surrogate pair).
