| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
case
|
|
|
|
Mostly to fix ui/issues/issue-37311-type-length-limit/issue-37311.rs.
Most parts of the compiler can handle deeply nested types with a lot
of duplicates just fine, but some parts still attempt to naively
traverse type tree.
Before such problems were caught by type length limit check,
but now these places will have to be changed to handle
duplicated types gracefully.
|
|
This fixes #72408.
Nested closures were resulting in exponential compilation time.
As a performance optimization this change introduces MiniSet,
which is a simple small storage optimized set.
|
|
This reverts commit 02eae432e7476a0686633a8c2b7cb1d5aab1bd2c.
|
|
This reverts commit 84fcd0dc991e2f5b9035d118d8c016f35ab37d0a.
|
|
This reverts commit e3856616ee2a894c7811a7017d98fafa7ba84dd8.
|
|
The logic is currently broken and we need to disable it to fix a beta
regression (see #76803)
|
|
Fix #75850.
|
|
Issue #74616 tracks a backwards-compatibility hack for certain macros.
This has is implemented by hard-coding the filenames and macro names of
certain code that we want to continue to compile.
However, the initial implementation of the hack was based on the
directory structure when building the crate from its repository (e.g.
`js-sys/src/lib.rs`). When the crate is build as a dependency, it will
include a version number from the clone from the cargo registry (e.g.
`js-sys-0.3.17/src/lib.rs`), which would fail the check.
This commit modifies the backwards-compatibility hack to check that
desired crate name (`js-sys` or `time-macros-impl`) is a prefix of the
proper part of the path.
See https://github.com/rust-lang/rust/issues/76070#issuecomment-687215646
for more details.
|
|
I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhaused isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with now-stable `contains`, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based is_empty plans, as the inherent ones are preferred in name resolution
|
|
doc: Prefer https link for wikipedia URLs
A tiny changes.
|
|
Provide better spans for the match arm without tail expression
Resolves #75418.
Applied the same logic in the `if`-`else` type mismatch case.
r? @estebank
|
|
Const floating point bitcasts and classification
Makes the `f32` and `f64` methods described in #72447 and #72505 unstably const.
r? @RalfJung
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
stabilize ptr_offset_from
This stabilizes ptr::offset_from, and closes https://github.com/rust-lang/rust/issues/41079. It also removes the deprecated `wrapping_offset_from`. This function was deprecated 19 days ago and was never stable; given an FCP of 10 days and some waiting time until FCP starts, that leaves at least a month between deprecation and removal which I think is fine for a nightly-only API.
Regarding the open questions in https://github.com/rust-lang/rust/issues/41079:
* Should offset_from abort instead of panic on ZSTs? -- As far as I know, there is no precedent for such aborts. We could, however, declare this UB. Given that the size is always known statically and the check thus rather cheap, UB seems excessive.
* Should there be more methods like this with different restrictions (to allow nuw/nsw, perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)? -- No reason to block stabilization on that, we can always add such methods later.
Also nominating the lang team because this exposes an intrinsic.
The stabilized method is best described [by its doc-comment](https://github.com/RalfJung/rust/blob/56d4b2d69abb93e4f0ca79471deca7aaaaeca214/src/libcore/ptr/const_ptr.rs#L227). The documentation forgot to mention the requirement that both pointers must "have the same provenance", aka "be derived from pointers to the same allocation", which I am adding in this PR. This is a precondition that [Miri already implements](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a3b9d0a07a01321f5202cd99e9613480) and that, should LLVM ever obtain a `psub` operation to subtract pointers, will likely be required for that operation (following the semantics in [this paper](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf)).
|
|
|
|
Use smaller def span for functions
Currently, the def span of a function encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}
```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
|
|
Re-land PR #72388: Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`
PR #72388 allowed us to preserve the original `TokenStream` in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See #72545 and #72622). These regressions fell into two categories
1. Missing handling for `Group`s with `Delimiter::None`, which are inserted during `macro_rules!` expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to `syn` and `proc-macro-hack`, but several crates needed changes to their own proc-macro code.
2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. [a compiliation error](https://github.com/paritytech/parity-scale-codec/pull/210) caused by misusing `quote_spanned!`). However, two crates had intentionally written unhygenic `macro_rules!` macros, which were able to access identifiers that were not passed as arguments (see https://github.com/rust-lang/rust/issues/72622#issuecomment-636402573).
All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at https://github.com/sammhicks/face-generator/pull/1) is not on `crates.io`, and is a Yew application that seems unlikely to have any reverse dependencies.
As @petrochenkov mentioned in https://github.com/rust-lang/rust/issues/72545#issuecomment-638632434, not re-landing PR #72388 allows more crates to write unhygenic `macro_rules!` macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic `macro_rules!` macros in the time it takes that PR to be merged.
|
|
Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
additional context for the recursive call.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
|
|
See issue #74616
|
|
Fixes #68430
This is a re-attempt of PR #72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
|
|
|
|
Gate if-let guard feature
Enhanced on #74315. That PR is in crater queue so I don't want to push to it.
Close #74232
cc #51114
|
|
|
|
r=jonas-schievink
Extend normalization in const-eval-query-stack test
Builds with debuginfo have additional information in backtrace.
|
|
Suppress "const" prefix of FnDef constants in MIR dump
I [was asked][1] to suppress the `const` infront of `FnDef`.
I tried to suppress comments for other types, but turned out that `const ()` and `()` is different: https://github.com/rust-lang/rust/pull/75697#discussion_r473892806
[1]: https://github.com/rust-lang/rust/pull/75670#issuecomment-675574333
|
|
Fix RFC-1014 test
Use two printlns when testing that writing to a closed stdout does not
panic. Otherwise the test is ineffective, since the current implementation
silently ignores the error during first println regardless.
|
|
Capture tokens for Pat used in macro_rules! argument
This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.
|
|
|
|
Builds with debuginfo have additional information in backtrace.
|
|
r=nikomatsakis
Don't immediately error for cycles during normalization
#73452 meant some normalization cycles could be detected earlier, breaking some code.
This PR makes defers errors for normalization cycles to fulfillment, fixing said code.
Fixes #74868
r? @nikomatsakis
|
|
|
|
Fix bad printing of const-eval queries
Fixes: #75447
r? @RalfJung
cc @oli-obk
|
|
Enable stack-overflow detection on musl for non-main threads
|
|
|
|
This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.
|
|
davidtwco:polymorphization-predicate-simplification-correction, r=eddyb
polymorphize: if any param in a predicate is used, then all are used
Addresses [review](https://github.com/rust-lang/rust/pull/75518#discussion_r470907646) [comments](https://github.com/rust-lang/rust/pull/75518#discussion_r470907865) [from](https://github.com/rust-lang/rust/pull/75518#discussion_r470908188) @eddyb in #75518 that I didn't get to resolve before bors merged.
This PR modifies polymorphization's handling of predicates so that if any generic parameter is used in a predicate then all parameters in that predicate are used.
r? @eddyb
|
|
move const param structural match checks to wfcheck
fixes #75047 fixes #74950
We currently check for structural match violations inside of `type_of`.
As we need to check the array length when checking if `[NonEq; arr_len]` is structural match, we potentially require the variance of an expression. Computing the variance requires `type_of` for all types though, resulting in a cycle error.
r? @varkor @eddyb
|
|
|
|
Doc alias checks: ensure only items appearing in search index can use it
Following the discussion in #73721, I added checks to ensure that only items appearing in the search are allowed to have doc alias.
r? @ollie27
|
|
Don't emit "is not a logical operator" error outside of associative expressions
Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.
Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.
Fixes #75599
---
First time contributor! Let me know if there are any conventions or policies I should be following that I missed here. Thanks :)
|
|
Fix clashing_extern_declarations stack overflow for recursive types.
Fixes #75512.
Adds a seen set to `structurally_same_type` to avoid recursing indefinitely for types which contain values of the same type through a pointer or reference.
|
|
|
|
|
|
|
|
|
|
Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.
Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.
Fixes #75599
|
|
It has been deny_by_default since 2017 (and warned for some time
before that), so it seems reasonable to promote it.
The specific technical motivation to do this now is to remove a field
from `ParseSess` -- it is a global state, and global state makes
extracting libraries annoying.
Closes #40107
|
