resolve: Preserve binding scopes in ambiguity errors
It allows to get rid of `AmbiguityErrorMisc`, `Flags` and `extern_prelude_flag_binding`.
Also keep all encountered bindings in `resolve_ident_in_scope_set`, it allows to get rid of `extern_prelude_item_binding`.
This also unblocks https://github.com/rust-lang/rust/pull/149681 because the newly preserved data will help to fix the regressions in https://github.com/rust-lang/rust/pull/149681#issuecomment-3679059703 in a reasonable way.
parser/lexer: bump to Unicode 17, use faster unicode-ident
Hello,
Bump the unicode version used by lexer/parser to 17.0.0 by updating:
- `unicode-normalization` to 0.1.25
- `unicode-properties` to 0.1.4
- `unicode-width` to 0.2.2
and by replacing `unicode-xid` with `unicode-ident` which is also 6 times faster.
I think it might be worth to run the benchmarks to double check.
(`unicode-ident` is already in `src/tools/tidy/src/deps.rs`)
Thanks!
Overhaul filename handling for cross-compiler consistency
This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`).
This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang/rust#148328).
In order to achieved consistency multiple steps are being taken by this PR:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue
- by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes
- this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename
In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed.
This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes.
Unblocks https://github.com/rust-lang/rust/pull/147611
Fixes https://github.com/rust-lang/rust/issues/148328
This commit refactors `SourceMap` and most importantly `RealFileName` to
make it self-contained in order to achieve cross-compiler consistency.
This is achieved:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- by also making `RealFileName` holds it's working directory,
it's embeddable name and the remapped scopes
- by making most `FileName` and `RealFileName` methods take a scope as
an argument
In order for `SourceMap::to_real_filename` to know which scopes to apply
`FilePathMapping` now takes the current remapping scopes to apply, which
makes `FileNameDisplayPreference` and company useless and are removed.
The scopes type `RemapPathScopeComponents` was moved from
`rustc_session::config` to `rustc_span`.
The previous system for scoping the local/remapped filenames
`RemapFileNameExt::for_scope` is no longer useful as it's replaced by
methods on `FileName` and `RealFileName`.
This allows LTO to work when compiling jemalloc, which should yield a
small performance boost, and makes miri's behaviour here match clippy
and rustdoc.
feat: Enable annotate-snippets' simd feature
`annotate-snippets` `simd` feature enables the use of `memchr` when searching for `char`/`str`. This should hopefully improve performance when [`annotate-snippets` is passed large `source`](https://github.com/rust-lang/rust/pull/148188#issuecomment-3550280300).
Bump compiler dependencies
https://github.com/rust-lang/rust/pull/145849#issuecomment-3394832713
This manually downgrades the `wasip`/`wit-bindgen`/`getrandom` deps to avoid pulling in a binary blob, but it would be good to pin this automatically in a way which doesn't cause these blobs to be pulled in.
rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution
Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index` (because it was defined in a different crate), you could only look it up it `Crate::paths`. But there, you don't get the full information, only an `ItemSummary`. This tells you the `path` and the `crate_id`.
But knowing the `crate_id` isn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get a `ExternalCrate` (via `Crate::external_crates`). But that only tells you the `name` (as a string). This isn't enough to uniquely identify a crate, as there could be multiple versions/features [^1] [^2].
This was originally proposed to be solved via `@LukeMathWalker's` `--orchestrator-id` proposal (https://github.com/rust-lang/compiler-team/issues/635). But that requires invasive changes to cargo/rustc. This PR instead implements `@Urgau's` proposal to re-use the path to a crate's rmeta/rlib as a unique identifer. Callers can use that to determine which package it corresponds to in the language of the build-system above rustc. E.g. for cargo, `cargo rustdoc --message-format=json --output-format=json -Zunstable-options`).
(Once you've found the right external crate's rustdoc-json output, you still need to resolve the path->id in that crate. But that's """just""" a matter of walking the module tree. We should probably still make that nicer (by, for example, allowing sharing `Id`s between rustdoc-json document), but that's a future concern)
For some notes from RustWeek 2025, where this was designed, see https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ
CC `@obi1kenobi` (who wants this for cargo-semver-checks [^3]), `@epage` (who's conversations on what and wasn't possible with cargo informed taking this approach to solve this problem)
r? `@GuillaumeGomez`
## TODO:
- [x] Docs: [Done](e4cdd0c24a..457ed4edb1)
- [x] Tests: [Done](2e1b954dc5..4d00c1a7ee)
[^1]: https://github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem
[^2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
[^3]: https://github.com/obi1kenobi/cargo-semver-checks/issues/638
Update memchr to 2.7.6
memchr 2.7.6 contains a bugfix for aarch64_be.
Note: I'm not sure about how dependency updates are managed in rust.git. If something should go through another branch or will happen automatically, please let me know.
