| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Before this two macros with same name would be indistinguishable inside a
`FileName`. This caused a bug in incremental compilation (see #53097) since
two different macros would map out to the same `StableFilemapId`.
Fixes #53097.
|
|
|
|
|
|
At least the incremental compilation code, and a few other places in the
compiler, require the CrateMetadata for a loaded target crate to contain a
valid DefIdTable for the DefIds in the target.
Previously, the CrateMetadata for a proc macro contained the crate's
"host" DefIdTable, which is of course incompatible with the "target"
DefIdTable, causing ICEs. This creates a DefIdTable that properly refers
to the "proc macro" DefIds.
Fixes #49482.
|
|
|
|
|
|
|
|
This is a clippy-breaking change.
|
|
|
|
|
|
|
|
Whenever we register a crate into the crate store, make sure to use the real
name mentioned in the metadata instead of the name mentioned in the `extern
crate` statement, as the statement can be wrong!
Closes #51796
|
|
|
|
|
|
|
|
Don’t mention `#[default_lib_allocator]` (which is an implementation detail
irrelevant to most users) and instead suggest using `#[global_allocator]`,
which is often the correct fix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make CrateNum allocation more thread-safe.
This PR makes sure that we can't have race conditions when assigning CrateNums. It's a slight improvement but a larger refactoring of the CrateStore/CrateLoader infrastructure would be good, I think.
r? @Zoxc
|
|
|
|
|
|
|
|
|
|
Fix save-analysis generation with extern_in_paths/extern_absolute_paths
Fixes #48742.
|
|
|
|
|
|
|
|
|
|
|
|
resolving it as a dependency.
Fixes #46816
|
|
Introduce a TargetTriple enum to support absolute target paths
This PR replaces target triple strings with a `TargetTriple` enum, which represents either a target triple or a path to a JSON target file. The path variant is used if the `--target` argument has a `.json` extension, else the target triple variant is used.
The motivation of this PR is support for absolute target paths to avoid the need for setting the `RUST_TARGET_PATH` environment variable (see rust-lang/cargo#4905 for more information). For places where some kind of triple is needed (e.g. in the sysroot folder), we use the file name (without extension).
For compatibility, we keep the old behavior of searching for a file named `$(target_triple).json` in `RUST_TARGET_PATH` for non-official target triples.
|
|
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
This contains all the actual profiling code.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
This commit adds a new attribute to the Rust compiler specific to the wasm
target (and no other targets). The `#[wasm_import_module]` attribute is used to
specify the module that a name is imported from, and is used like so:
#[wasm_import_module = "./foo.js"]
extern {
fn some_js_function();
}
Here the import of the symbol `some_js_function` is tagged with the `./foo.js`
module in the wasm output file. Wasm-the-format includes two fields on all
imports, a module and a field. The field is the symbol name (`some_js_function`
above) and the module has historically unconditionally been `"env"`. I'm not
sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd
like the ability to configure it!
The proposed ES module integration with wasm (aka a wasm module is "just another
ES module") requires that the import module of wasm imports is interpreted as an
ES module import, meaning that you'll need to encode paths, NPM packages, etc.
As a result, we'll need this to be something other than `"env"`!
Unfortunately neither our version of LLVM nor LLD supports custom import modules
(aka anything not `"env"`). My hope is that by the time LLVM 7 is released both
will have support, but in the meantime this commit adds some primitive
encoding/decoding of wasm files to the compiler. This way rustc postprocesses
the wasm module that LLVM emits to ensure it's got all the imports we'd like to
have in it.
Eventually I'd ideally like to unconditionally require this attribute to be
placed on all `extern { ... }` blocks. For now though it seemed prudent to add
it as an unstable attribute, so for now it's not required (as that'd force usage
of a feature gate). Hopefully it doesn't take too long to "stabilize" this!
cc rust-lang-nursery/rust-wasm#29
|
|
syntax: Make imports in AST closer to the source and cleanup their parsing
This is a continuation of https://github.com/rust-lang/rust/pull/45846 in some sense.
|
|
|
|
|
|
what it is doing.
|
|
|
|
|
|
Upgrade `log` to `0.4` in multiple crates.
|
|
|
|
|
