| Age | Commit message (Collapse) | Author | Lines |
|---|
|
[breaking change] Validate crate name in `--extern` [MCP 650]
Reject non-ASCII-identifier crate names passed to the CLI option `--extern` (`rustc`, `rustdoc`).
Implements [MCP 650](https://github.com/rust-lang/compiler-team/issues/650) (except that we only allow ASCII identifiers not arbitrary Rust identifiers).
Fixes #113035.
[As mentioned on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Disallow.20non-identifier-valid.20--extern.20cr.E2.80.A6.20compiler-team.23650/near/376826988), doing a crater run probably doesn't make sense since it wouldn't yield anything. Most users don't interact with `rustc` directly but only ever through Cargo which always passes a valid crate name to `--extern` when it invokes `rustc` and `rustdoc`. In any case, the user wouldn't be able to use such a crate name in the source code anyway.
Note that I'm not using [`rustc_session::output::validate_crate_name`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/output/fn.validate_crate_name.html) (used for `--crate-name` and `#![crate_name]`) since the latter doesn't reject non-ASCII crate names and ones that start with a digit.
As an aside, I've also thought about getting rid of `validate_crate_name` entirely in a separate PR (with another MCP) in favor of `is_ascii_ident` to reject more weird `--crate-name`s, `#![crate_name]`s and file names but I think that would lead to a lot of actual breakage, namely because of file names starting with a digit. In `tests/ui` 9 tests would be impacted for example.
CC `@estebank`
r? `@est31`
|
|
adjust how closure/generator types are printed
I saw `&[closure@$DIR/issue-20862.rs:2:5]` and I thought it is a slice type, because that's usually what `&[_]` is... it took me a while to realize that this is just a confusing printer and actually there's no slice. Let's use something that cannot be mistaken for a regular type.
|
|
Allow `-Z treat-err-as-bug=0`
Makes `-Z treat-err-as-bug=0` behave as if the option wasn't present instead of asking the value to be ⩾ 1. This enables a quick on/off of the option, as you only need to change one character instead of removing the whole `-Z`.
Also update some text, e.g.
```bash
$ rustc -Z help | grep treat-err-as-bug
-Z treat-err-as-bug=val -- treat error number `val` that occurs as bug
```
where the value could be interpreted as an error code instead of an ordinal.
|
|
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
Rollup of 7 pull requests
Successful merges:
- #114379 (Command: also print removed env vars)
- #116034 (add UI test for delimiter errors)
- #116036 (tests/ui: Split large_moves.rs and move to lint/large_assignments)
- #116038 (Fall back to _SC_NPROCESSORS_ONLN if sched_getaffinity returns an empty mask)
- #116039 (Account for nested `impl Trait` in TAIT)
- #116041 (Add note to `is_known_rigid`)
- #116049 (give FutureIncompatibilityReason variants more explicit names)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
give FutureIncompatibilityReason variants more explicit names
Also make the `reason` field mandatory when declaring a lint, to make sure this is a deliberate decision.
|
|
Add note to `is_known_rigid`
Adds a note requested by `@RalfJung` in https://github.com/rust-lang/rust/pull/114941#discussion_r1329963704
Let me know if there are any other fns that need documentation, I could throw them into this PR too :)
|
|
Account for nested `impl Trait` in TAIT
Fix #116031.
r? `@compiler-errors`
|
|
Fall back to _SC_NPROCESSORS_ONLN if sched_getaffinity returns an empty mask
Followup to #115946
A gentler fix for #115868, one that doesn't panic, [suggested on zulip](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202023-09-19/near/391942927)
In that situation - on the buggy kernel versions - a zero-mask means no affinities have been set so `_SC_NPROCESSORS_ONLN` provides the right value.
|
|
tests/ui: Split large_moves.rs and move to lint/large_assignments
To make failing tests easier to debug with `--emit=mir`, etc.
Don't bother with `revisions: attribute option` for both tests though. Seems sufficient to just have that on one of the tests.
`git show -M --find-renames=40%` makes the diff easier to review. Or note that before this change we had one test with 4 errors, now we have 2 tests with 2 errors each.
r? `@oli-obk`
Part of https://github.com/rust-lang/rust/issues/83518
|
|
add UI test for delimiter errors
Fixes #98601
from https://github.com/rust-lang/rust/issues/98601#issuecomment-1721515067
r? `@estebank`
|
|
Command: also print removed env vars
There is no real shell syntax for unsetting an env var so easily, so we have to make one up. But we already do that for showing the 'program' name so I hope that's okay here, too. No strong opinion on what that should look like, I went with `unset(VAR_NAME)` for now.
|
|
add more explicit I/O safety documentation
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/434
Cc https://github.com/rust-lang/rust/issues/114167
Cc `@Manishearth` `@sunfishcode` `@joshtriplett`
|
|
|
|
Enable effects for libcore
~~r? `@oli-obk~~`
forgot you are on vacation, oops
|
|
|
|
|
|
Prevent using `#[target_feature]` on lang item functions
Fixes https://github.com/rust-lang/rust/issues/109411 and also prevents from using `#[target_feature]` on other `fn` lang items to mitigate the concerns from https://github.com/rust-lang/rust/issues/109411#issuecomment-1477030273.
|
|
|
|
Move `DepKind` to `rustc_query_system` and define it as `u16`
This moves the `DepKind` type to `rustc_query_system` where it's defined with an inner `u16` field. This decouples it from `rustc_middle` and is a step towards letting other crates define dep kinds. It also allows some type parameters to be removed. The `DepKind` trait is replaced with a `Deps` trait. That's used when some operations or information about dep kinds which is unavailable in `rustc_query_system` are still needed.
r? `@cjgillot`
|
|
|
|
rustc_hir_analysis: add a helper to check function the signature mismatches
This function is now used to check `#[panic_handler]`, `start` lang item, `main`, `#[start]` and intrinsic functions.
The diagnosis produced are now closer to the ones produced by trait/impl method signature mismatch.
This is the first time I do anything with rustc_hir_analysis/rustc_hir_typeck, so comments and suggestions about things I did wrong or that could be improved will be appreciated.
|
|
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound
First commit allows us to store the span of the `async` keyword in HIR.
Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in #115822.
This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
|
|
|
|
added support for GNU/Hurd
adding support for i686-unknown-hurd-gnu
|
|
|
|
|
|
To make failing tests easier to debug with --emit=mir, etc.
|
|
|
|
Fix #116031.
|
|
coverage: Don't bother renumbering expressions on the Rust side
The LLVM API that we use to encode coverage mappings already has its own code for removing unused coverage expressions and renumbering the rest.
This lets us get rid of our own complex renumbering code, making it easier to change our coverage code in other ways.
---
Now that we have tests for coverage mappings (#114843), I've been able to verify that this PR doesn't make the coverage mappings worse, thanks to an explicit simplification step.
|
|
We only want the attribute for the attribute revision.
|
|
|
|
|
|
|
|
interpret: more consistently use ImmTy in operators and casts
The diff in src/tools/miri/src/shims/x86/sse2.rs should hopefully suffice to explain why this is nicer. :)
|
|
Rollup of 5 pull requests
Successful merges:
- #115257 (Improve invalid UTF-8 lint by finding the expression initializer)
- #115936 (Prevent promotion of const fn calls in inline consts)
- #115972 (rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const)
- #116007 (Call panic_display directly in const_panic_fmt.)
- #116019 (Delete obsolete `--disable-per-crate-search` rustdoc flag)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Delete obsolete `--disable-per-crate-search` rustdoc flag
This unstable flag is unused by rustdoc since https://github.com/rust-lang/rust/pull/92526/commits/ef96d573bff12330080d22f12cad96b818ea5da7.
We should avoid landing this until after https://github.com/rust-lang/docs.rs/pull/2225 is deployed to docs.rs.
|
|
Call panic_display directly in const_panic_fmt.
`panic_str` just directly calls `panic_display`. The only reason `panic_str` exists, is for a lint to detect an expansion of `panic_2015!(expr)` (which expands to `panic_str`).
It is `panic_display` that is hooked by const-eval, which is the reason we call it here.
Part of https://github.com/rust-lang/rust/issues/116005
r? ``@oli-obk``
|
|
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const
Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`.
Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all.
However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish...
``@oli-obk`` any ideas?
|
|
Prevent promotion of const fn calls in inline consts
We don't wanna make that mistake we did for statics and consts worse by letting more code use it.
r? ``@RalfJung``
cc https://github.com/rust-lang/rust/issues/76001
|
|
Improve invalid UTF-8 lint by finding the expression initializer
This PR introduce a small mechanism to walk up the HIR through bindings, if/else, consts, ... when trying lint on invalid UTF-8.
Fixes https://github.com/rust-lang/rust/issues/115208
|
|
|
|
|
|
The LLVM API that we use to encode coverage mappings already has its own code
for removing unused coverage expressions and renumbering the rest.
This lets us get rid of our own complex renumbering code, making it easier to
change our coverage code in other ways.
|
|
After coverage instrumentation and MIR transformations, we can sometimes end up
with coverage expressions that always have a value of zero. Any expression
operand that refers to an always-zero expression can be replaced with a literal
`Operand::Zero`, making the emitted coverage mapping data smaller and simpler.
This simplification step is mostly redundant with the simplifications performed
inline in `expressions_with_regions`, except that it does a slightly more
thorough job in some cases (because it checks for always-zero expressions
*after* other simplifications).
However, adding this simplification step will then let us greatly simplify that
code, without affecting the quality of the emitted coverage maps.
|
|
|
|
|
|
implement `intercrate_ambiguity_causes` in the new solver
I added some comments but this is still somewhat of a mess. I think we should for the most part be able to treat all of this as a black box, so I can accept that this code isn't too great.
I also believe that some of the weirdness here is unavoidable, as proof trees - and their visitor - hide semantically relevant information, so they cannot perfectly represent the actual solver behavior.
There are some known bugs here when testing with `./x.py test tests/ui --bless -- --target-rustcflags -Ztrait-solver=next-coherence`. While I haven't diagnosed them all in detail I believe we are able to handle them all separately
- `structurally_normalize` currently does not normalize opaque types, resulting in divergence between the solver internal `trait_ref_is_knowable` and the one when computing intercrate ambiguity causes.
- we don't add an `intercrate_ambiguity_cause` for reserved impls
- we should `deeply_normalize` the trait ref before printing it, that requires a "best effort" version of `deeply_normalize`
r? `@compiler-errors`
|
|
|
