| Age | Commit message (Collapse) | Author | Lines |
|---|
|
uninhabited_reference: new lint
Close #11851
The lint is implemented on function parameters and return types, as this is the place where the risk of exchanging references to uninhabited types is the highest. Other constructs, such as in a local variable,
would require the use of `unsafe` and will clearly be done on purpose.
changelog: [`uninhabited_reference`]: new lint
|
|
LLVM commit https://github.com/llvm/llvm-project/commit/1d608fc755a3e15d0020f61c9535c9b730ab9dec
renamed the pass.
|
|
|
|
|
|
Implement repr(packed) for repr(simd)
This allows creating vectors with non-power-of-2 lengths that do not have padding. See rust-lang/portable-simd#319
|
|
Fix `is_from_proc_macro` patterns
fixes #11533
changelog: none
|
|
r=Mark-Simulacrum
Rearrange `default_configuration` and `CheckCfg::fill_well_known`.
There are comments saying these two functions should be kept in sync, but they have very different structures, process symbols in different orders, and there are some inconsistencies.
This commit reorders them so they're both mostly processing symbols in alphabetical order, which makes cross-checking them a lot easier. The commit also adds some macros to factor out repetitive code patterns.
The commit also moves the handling of `sym::test` out of `build_configuration` into `default_configuration`, where all the other symbols are handled.
r? `@bjorn3`
|
|
Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>
|
|
Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>
|
|
guarantee that char and u32 are ABI-compatible
In https://github.com/rust-lang/rust/pull/116894 we added a guarantee that `char` has the same alignment as `u32`, but there is still one axis where these types could differ: function call ABI. So let's nail that down as well: in a function signature, `char` and `u32` are completely equivalent.
This is a new stable guarantee, so it will need t-lang approval.
|
|
|
|
Revert using MCP510 in bootstrap
This reverts commit 40c3d351ada5d991f7474ecc4bc6c9b976c656cb. The commit started dogfooding MCP510 to enable `lld` when building the compiler , but it broke tests, because we don't pass `-Zunstable-options` on enough places. This PR hotfixes that, and temporarily makes the "self-contained" option.. not very self-contained. I'll send a proper fix later, but I want to unblock rustc developres that use `lld` locally.
r? `@nnethercote` (who discovered the problem)
|
|
Improve `print_tts`
By slightly changing the meaning of `tokenstream::Spacing` we can greatly improve the output of `print_tts`.
r? `@ghost`
|
|
Before: http://notriddle.com/rustdoc-html-demo-6/tor-before/tor_config/
After: http://notriddle.com/rustdoc-html-demo-6/tor-after/tor_config/
Profile: http://notriddle.com/rustdoc-html-demo-6/tor-profile/
As a bit of background information: in type-based queries, a type
name that does not exist gets treated as a generic type variable.
This causes a counterintuitive behavior in the `tor_config` crate,
which has a trait with an associated type variable called `T`.
This isn't a searchable concrete type, but its name still gets stored
in the typeNameIdMap, as a convenient way to intern its name.
|
|
There are comments saying these two functions should be kept in sync,
but they have very different structures, process symbols in different
orders, and there are some inconsistencies.
This commit reorders them so they're both mostly processing symbols in
alphabetical order, which makes cross-checking them a lot easier. The
commit also adds some macros to factor out repetitive code patterns.
Plus it adds `sanitizer_cfi_normalize_{integers,pointers}` to
`fill_well_known`, which were missing.
The commit also moves the handling of `sym::test` out of
`build_configuration` into `default_configuration`, where all the other
symbols are handled.
|
|
Because the spacing-based pretty-printing partially preserves that.
|
|
This is an extension of the previous commit. It means the output of
something like this:
```
stringify!(let a: Vec<u32> = vec![];)
```
goes from this:
```
let a: Vec<u32> = vec![] ;
```
With this PR, it now produces this string:
```
let a: Vec<u32> = vec![];
```
|
|
This is an extension of the previous commit. It means the output of
something like this:
```
stringify!(let a: Vec<u32> = vec![];)
```
goes from this:
```
let a: Vec<u32> = vec![] ;
```
With this PR, it now produces this string:
```
let a: Vec<u32> = vec![];
```
|
|
WaffleLapkin:don't-emit-missing-assoc-items-diagnostic-for-negative-impls, r=Veykril
fix: Don't emit "missing items" diagnostic for negative impls
Negative impls can't have items, so there is no reason for this diagnostic.
LMK if I should add a test somewhere. Also LMK if that's not how we usually check multiple things in an if in r-a.
|
|
This reverts commit 40c3d351ada5d991f7474ecc4bc6c9b976c656cb. The option was dogfooded for using lld with MCP510 , but it broke testing with LLD, because we don't pass `-Zunstable-options` on enough places.
|
|
|
|
`tokenstream::Spacing` appears on all `TokenTree::Token` instances,
both punct and non-punct. Its current usage:
- `Joint` means "can join with the next token *and* that token is a
punct".
- `Alone` means "cannot join with the next token *or* can join with the
next token but that token is not a punct".
The fact that `Alone` is used for two different cases is awkward.
This commit augments `tokenstream::Spacing` with a new variant
`JointHidden`, resulting in:
- `Joint` means "can join with the next token *and* that token is a
punct".
- `JointHidden` means "can join with the next token *and* that token is a
not a punct".
- `Alone` means "cannot join with the next token".
This *drastically* improves the output of `print_tts`. For example,
this:
```
stringify!(let a: Vec<u32> = vec![];)
```
currently produces this string:
```
let a : Vec < u32 > = vec! [] ;
```
With this PR, it now produces this string:
```
let a: Vec<u32> = vec![] ;
```
(The space after the `]` is because `TokenTree::Delimited` currently
doesn't have spacing information. The subsequent commit fixes this.)
The new `print_tts` doesn't replicate original code perfectly. E.g.
multiple space characters will be condensed into a single space
character. But it's much improved.
`print_tts` still produces the old, uglier output for code produced by
proc macros. Because we have to translate the generated code from
`proc_macro::Spacing` to the more expressive `token::Spacing`, which
results in too much `proc_macro::Along` usage and no
`proc_macro::JointHidden` usage. So `space_between` still exists and
is used by `print_tts` in conjunction with the `Spacing` field.
This change will also help with the removal of `Token::Interpolated`.
Currently interpolated tokens are pretty-printed nicely via AST pretty
printing. `Token::Interpolated` removal will mean they get printed with
`print_tts`. Without this change, that would result in much uglier
output for code produced by decl macro expansions. With this change, AST
pretty printing and `print_tts` produce similar results.
The commit also tweaks the comments on `proc_macro::Spacing`. In
particular, it refers to "compound tokens" rather than "multi-char
operators" because lifetimes aren't operators.
|
|
Return MAP_FAILED when mmap fails
I don't properly remember why we ended up with a hodgepodge of return values, but https://github.com/rust-lang/miri/issues/3218 correctly points out that we are supposed to return `MAP_FAILED`. This should fix that return value and also add sufficient tests to prevent making a similar mistake.
|
|
|
|
Implement `--env` compiler flag (without `tracked_env` support)
Part of https://github.com/rust-lang/rust/issues/80792.
Implementation of https://github.com/rust-lang/compiler-team/issues/653.
Not an implementation of https://github.com/rust-lang/rfcs/pull/2794.
It adds the `--env` compiler flag option which allows to set environment values used by `env!` and `option_env!`.
Important to note: When trying to retrieve an environment variable value, it will first look into the ones defined with `--env`, and if there isn't one, then only it will look into the environment variables. So if you use `--env PATH=a`, then `env!("PATH")` will return `"a"` and not the actual `PATH` value.
As mentioned in the title, `tracked_env` support is not added here. I'll do it in a follow-up PR.
r? rust-lang/compiler
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
|
|
|
|
|
|
Remove unused bootstrap config option
I tried to destructure a few of the TOML config structs to find any unused fields. I found that `Rust::run_dysmutil` field is unused. This PR uses destructuring of the `Rust` struct, to find similar unused fields in the future, and also removes the unused field.
I also found one more unused field (`Dist::gpg_password_file`), it doesn't seem to be used anywhere. If you like this PR, I'll send another one that uses destructuring for all interesting TOML structs and removes that unused field.
r? `@onur-ozkan`
|
|
|
|
|
|
This will allow us to check if all values are used
|
|
Add `blyxyas` to `users_on_vacation`
I have a surgery this Wednesday, so I won't be able to review anything from that day up to (at least) Dec. 22, I'll open another PR by then.
I'm not sure if `users_on_vacation` will work here, if it doesn't work, I'll just remove myself from the reviewer rotation
changelog:none
|
|
Use immediate_backend_type when reading from a const alloc
Fixes https://github.com/rust-lang/rust/issues/118047
r? `@nikic`
|
|
|
|
|
|
Fix miri script target dir and update doc link
Fix ui_test doc link in `CONTRIBUTING.md`
Explicitly set `--target-dir` in `miri` script when building to expected location
- I have `build.target-dir` cargo config set to be some other location so miri script was erroring out since compiled binary was not in expected location
|
|
Implement 2024-edition lifetime capture rules RFC
Implements rust-lang/rfcs#3498.
|
|
|
|
Generalize LLD usage in bootstrap
The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed:
> Indicates whether LLD will be used to link Rust crates during bootstrap on
> supported platforms. The LLD from the bootstrap distribution will be used
> and not the LLD compiled during the bootstrap.
What it did:
1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since https://github.com/rust-lang/rust/pull/102101), therefore it wouldn't work if `lld` wasn't available.
2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail.
This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH.
In addition, this PR also dog-foods [MCP510](https://github.com/rust-lang/compiler-team/issues/510) in bootstrap.
To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets.
Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`.
Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler).
Best reviewed commit by commit.
CC `@petrochenkov`
|
|
fix: Fix view mir, hir and eval function not working when cursor is inside macros
I broke the view ones completely by inverting the macro check by accident a few days ago but we don't talk about that.
|
|
macros
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
