| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
r=petrochenkov
Properly allow macro expanded `format_args` invocations to uses captures
Originally, this was kinda half-allowed. There were some primitive checks in place that looked at the span to see whether the input was likely a literal. These "source literal" checks are needed because the spans created during `format_args` parsing only make sense when it is indeed a literal that was written in the source code directly.
This is orthogonal to the restriction that the first argument must be a "direct literal", not being exanpanded from macros. This restriction was imposed by [RFC 2795] on the basis of being too confusing. But this was only concerned with the argument of the invocation being a literal, not whether it was a source literal (maybe in spirit it meant it being a source literal, this is not clear to me).
Since the original check only really cared about source literals (which is good enough to deny the `format_args!(concat!())` example), macros expanding to `format_args` invocations were able to use implicit captures if they spanned the string in a way that lead back to a source string.
The "source literal" checks were not strict enough and caused ICEs in certain cases (see #106191). So I tightened it up in #106195 to really only work if it's a direct source literal.
This caused the `indoc` crate to break. `indoc` transformed the source literal by removing whitespace, which made it not a "source literal" anymore (which is required to fix the ICE). But since `indoc` spanned the literal in ways that made the old check think that it's a literal, it was able to use implicit captures (which is useful and nice for the users of `indoc`).
This commit properly seperates the previously introduced concepts of "source literal" and "direct literal" and therefore allows `indoc` invocations, which don't create "source literals" to use implicit captures again.
Fixes #106191
[RFC 2795]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
|
|
Originally, this was kinda half-allowed. There were some primitive
checks in place that looked at the span to see whether the input was
likely a literal. These "source literal" checks are needed because the
spans created during `format_args` parsing only make sense when it is
indeed a literal that was written in the source code directly.
This is orthogonal to the restriction that the first argument must be a
"direct literal", not being exanpanded from macros. This restriction was
imposed by [RFC 2795] on the basis of being too confusing. But this was
only concerned with the argument of the invocation being a literal, not
whether it was a source literal (maybe in spirit it meant it being a
source literal, this is not clear to me).
Since the original check only really cared about source literals (which
is good enough to deny the `format_args!(concat!())` example), macros
expanding to `format_args` invocations were able to use implicit
captures if they spanned the string in a way that lead back to a source
string.
The "source literal" checks were not strict enough and caused ICEs in
certain cases (see # 106191 (the space is intended to avoid spammy
backreferences)). So I tightened it up in # 106195 to really only work
if it's a direct source literal.
This caused the `indoc` crate to break. `indoc` transformed the source
literal by removing whitespace, which made it not a "source literal"
anymore (which is required to fix the ICE). But since `indoc` spanned
the literal in ways that made the old check think that it's a literal,
it was able to use implicit captures (which is useful and nice for the
users of `indoc`).
This commit properly seperates the previously introduced concepts of
"source literal" and "direct literal" and therefore allows `indoc`
invocations, which don't create "source literals" to use implicit
captures again.
[RFC 2795]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
|
|
Remove `identity_future` indirection
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]`annotation.
Fixes https://github.com/rust-lang/rust/issues/104826.
|
|
resolve: Querify most cstore access methods (subset)
A subset of https://github.com/rust-lang/rust/pull/108346 that is not on a hot path in any way.
|
|
r=compiler-errors
Gracefully handle `#[target_feature]` on statics
The was careful around not calling `fn_sig` on not-functions but well, it wasn't careful enough. This commit makes it a little more careful and also adds tests for a bunch more item kinds.
I was sadly not able to fully bless the test locally because I'm on an aarch64 machine but I hope some manual editing made it work 😅
Fix #109079
|
|
simd-wide-sum test: adapt for LLVM 17 codegen change
After https://github.com/llvm/llvm-project/commit/0d4a709bb876824a0afa5f86e138e8ffdcaf7661 LLVM becomes more clever and turns ```@wider_reduce_loop``` into an alias:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/17806#0186da6b-582c-46bf-a227-1565fa0859ac/743-766
This adapts the test to prevent this.
|
|
Treat projections with infer as placeholder during fast reject in new solver
r? ``@lcnr``
Kind of a shame that we need to change all of the call sites for `for_each_relevant_impl`, etc. to pass an extra parameter. I guess I could have the "default" fn which calls a configurable fn?
|
|
The was careful around not calling `fn_sig` on not-functions but well,
it wasn't careful enough. This commit makes it a little more careful and
also adds tests for a bunch more item kinds.
|
|
|
|
|
|
After https://github.com/llvm/llvm-project/commit/0d4a709bb876824a0afa5f86e138e8ffdcaf7661
LLVM becomes more clever and turns `@wider_reduce_loop` into an alias:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/17806#0186da6b-582c-46bf-a227-1565fa0859ac/743-766
This adapts the test to prevent this.
|
|
Move `Option::as_slice` to an always-sound implementation
This approach depends on CSE to not have any branches or selects when the guessed offset is correct -- which it always will be right now -- but to also be *sound* (just less efficient) if the layout algorithms change such that the guess is incorrect.
The codegen test confirms that CSE handles this as expected, leaving the optimal codegen.
cc JakobDegen #108545
|
|
|
|
Remove `box_syntax`
r? `@Nilstrieb`
This removes the feature `box_syntax`, which allows the use of `box <expr>` to create a Box, and finalises removing use of the feature from the compiler. `box_patterns` (allowing the use of `box <pat>` in a pattern) is unaffected.
It also removes `ast::ExprKind::Box` - the only way to create a 'box' expression now is with the rustc-internal `#[rustc_box]` attribute.
As a temporary measure to help users move away, `box <expr>` now parses the inner expression, and emits a `MachineApplicable` lint to replace it with `Box::new`
Closes #49733
|
|
Strengthen state tracking in const-prop
Some/many of the changes are replicated between both the const-prop lint and the const-prop optimization.
Behaviour changes:
- const-prop opt does not give a span to propagated values. This was useless as that span's primary purpose is to diagnose evaluation failure in codegen.
- we remove the `OnlyPropagateInto` mode. It was only used for function arguments, which are better modeled by a write before entry.
- the tracking of assignments and discriminants make clearer that we do nothing in `NoPropagation` mode or on indirect places.
|
|
Gate usages of `dyn*` and const closures in macros
We silently accepted `dyn*` and const closures in macros as long as they didn't expand to anything containing these experimental features, unlike other gated features such as `for<'a>` binders on closures, etc. Let's not do that, to make sure nobody begins relying on this.
|
|
rustdoc: use restricted Damerau-Levenshtein distance for search
Based on https://github.com/rust-lang/rust/pull/108200, for the same rationale.
> This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a restricted implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.
Before this change, searching [`prinltn!`] listed `print!` first, followed by `println!`. With this change, `println!` matches more closely.
[`prinltn!`]: https://doc.rust-lang.org/nightly/std/?search=prinltn!
|
|
|
|
|
|
|
|
|
|
|
|
Commit some tests for the new solver + lazy norm
Also consolidate `typeck/lazy-norm` into `traits/new-solver`, since it's not really useful to maintain a distinction, like when a test really is due to "lazy norm" or "the new solver" (usually both!)
|
|
Add suggestion to diagnostic when user has array but trait wants slice. (rebased)
Rebase of #91314, except for change to multipart suggestion
Resolves #90528
r? ``@compiler-errors`` since you requested the multipart suggestion
|
|
This approach depends on CSE to not have any branches or selects when the guessed offset is correct -- which it always will be right now -- but to also be *sound* (just less efficient) if the layout algorithms change such that the guess is incorrect.
|
|
Make RPITITs simple cases work when using lower_impl_trait_in_trait_to_assoc_ty
r? `@compiler-errors`
It's probably best reviewed commit by commit.
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #104363 (Make `unused_allocation` lint against `Box::new` too)
- #106633 (Stabilize `nonzero_min_max`)
- #106844 (allow negative numeric literals in `concat!`)
- #108071 (Implement goal caching with the new solver)
- #108542 (Force parentheses around `match` expression in binary expression)
- #108690 (Place size limits on query keys and values)
- #108708 (Prevent overflow through Arc::downgrade)
- #108739 (Prevent the `start_bx` basic block in codegen from having two `Builder`s at the same time)
- #108806 (Querify register_tools and post-expansion early lints)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Force parentheses around `match` expression in binary expression
This attempts to solve https://github.com/rust-lang/rust/issues/98790.
|
|
allow negative numeric literals in `concat!`
Fixes #106837
While *technically* negative numeric literals are implemented as unary operations, users can reasonably expect that negative literals are treated the same as positive literals.
|
|
Make `unused_allocation` lint against `Box::new` too
Previously it only linted against `box` syntax, which likely won't ever be stabilized, which is pretty useless. Even now I'm not sure if it's a meaningful lint, but it's at least something :shrug:
This means that code like the following will be linted against:
```rust
Box::new([1, 2, 3]).len();
f(&Box::new(1)); // where f : &i32 -> ()
```
The lint works by checking if a `Box::new` (or `box`) expression has an a borrow adjustment, meaning that the code that first stores the box in a variable won't be linted against:
```rust
let boxed = Box::new([1, 2, 3]); // no lint
boxed.len();
```
|
|
rustdoc: Don't crash on `crate` references in blocks
This is a regression from #94857.
|
|
Honor current target when checking conditional compilation values
This is fixed by simply using the currently registered target in the current session. We need to use it because of target json that are not by design included in the rustc list of targets.
Fixes https://github.com/rust-lang/rust/issues/108941
|
|
Move __thread_local_inner to sys
Move `__thread_local_inner` macro in `crate::thread::local` to `crate::sys`. Initially, I was thinking about removing this macro completely, but I could not find a way to create the generic statics without macros, so in the end, I just moved to code around.
This probably will need a rebase once https://github.com/rust-lang/rust/pull/108917 is merged
r? ``@workingjubilee``
|
|
Add note when matching token with nonterminal
The current error message is _really_ confusing. The implementation is slightly hacky, but not that much more hacky than all this nonterminal stuff..
r? ``@petrochenkov``
|
|
Rollup of 8 pull requests
Successful merges:
- #105798 (Relax ordering rules for `asm!` operands)
- #105962 (Stabilize path_as_mut_os_str)
- #106085 (use problem matchers for tidy CI)
- #107711 (Stabilize movbe target feature)
- #108017 (Add `--no-undefined-version` link flag and fix associated breakage)
- #108891 (Remove an extraneous include)
- #108902 (no more do while :<)
- #108912 (Document tool lints)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Based on https://github.com/rust-lang/rust/pull/108200, for the same
rationale.
> This replaces the existing Levenshtein algorithm with the
> Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change
> (a transposition) instead of two (a deletion and insertion). More
> specifically, this is a restricted implementation, in that "ca" to "abc"
> cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the
> middle of a transposition. I believe that errors like that are sufficiently
> rare that it's not worth taking into account.
Before this change, searching `prinltn!` listed `print!` first, followed
by `println!`. With this change, `println!` matches more closely.
|
|
Relax ordering rules for `asm!` operands
The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order:
- Template strings
- Positional operands
- Named operands
- Explicit register operands
- `clobber_abi`
- `options`
This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows:
- Template strings must still come before all other operands.
- Positional operands must still come before named and explicit register operands.
- Named and explicit register operands can be freely mixed.
- `options` and `clobber_abi` can appear in any position after the template strings.
r? ```````@joshtriplett```````
|
|
LeSeulArtichaut:108646-target-feature-default-impl, r=cjgillot
Forbid `#[target_feature]` on safe default implementations
Fixes #108646.
|
|
Don't even try to combine consts with incompatible types
~I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a `ConstArgHasType` predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.~
1. Use the `type_of` for a parameter in `try_eval_lit_or_param`, instead of the "expected" type from a `WithOptConstParam` def id.
2. Don't combine consts that have incompatible types.
Fixes #108781
|
|
r=petrochenkov
feat: implement better error for manual impl of `Fn*` traits
Fixes #39259
cc `@estebank` (you gave me some advice in the linked issue, would you like to review?)
|
|
fix(lexer): print whitespace warning for \x0c
- close https://github.com/rust-lang/rust/issues/108275
- discussion: https://github.com/rust-lang/rust/pull/108403
|
|
Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type
We never supported solving `for<'a> fn(&'a ()): Fn(&'a ())` -- I tried to add that support in #104929, but iirc `@lcnr` wanted to support this more generally by eagerly instantiating trait predicate binders with placeholders. That never happened due to blockers in the old solver, but we probably shouldn't ICE in any case.
On the bright side, this passes on the new solver :^)
|
|
Emit alias-eq when equating numeric var and projection
This doesn't fix everything having to do with projections and infer vars, but it does fix a common case I saw in HIR typeck.
r? `@lcnr`
|
|
This allows removing all the platform-dependent code from `library/std/src/thread/local.rs` and `library/std/src/thread/mod.rs`
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
|
