"A 'declare' modifier cannot be used in an already ambient context" after upgrading to version 0.27.35

[haykam821]

Bug description

When upgrading to version 0.27.35, I am getting a new error in my builds:

> tsc

../../node_modules/assemblyscript/std/assembly/index.d.ts:2698:3 - error TS1038: A 'declare' modifier cannot be used in an already ambient context.

2698   declare function always<T>(value: T): T;
       ~~~~~~~


Found 1 error in ../../node_modules/assemblyscript/std/assembly/index.d.ts:2698

The changelog for the release does not indicate any particular change that would cause this breakage. The corresponding lines of code appear to be:

assemblyscript/std/assembly/builtins.ts

Lines 205 to 209 in 4e7734b

	export namespace inline {
	// @ts-ignore: decorator
	@unsafe @builtin
	export declare function always<T>(expr: T): T;
	}

Steps to reproduce

The particular package that fails to build uses the following TypeScript configuration with tsc:

{
	"compilerOptions": {
		"outDir": "./dist",
		"rootDir": "./src"
	},
	"extends": "assemblyscript/std/assembly.json",
	"include": [
		"./src"
	]
}

AssemblyScript version

v0.27.35

[mattjohnsonpint]

Well, the changelog for 0.27.35 does indeed reference #2895 which is where the new function that came from.

I see you're using tsc not asc, so I presume your code using AssemblyScript's portability features. @CountBleck - perhaps this is a portability issue?

[CountBleck]

I suppose that's what I get for writing that part on my phone, without IntelliSense...
In any case, the next release (around 12 AM UTC) should fix this.

[haykam821]

Thank you! Version 0.27.36 resolved the build issue on my end.

Regarding the tsc mention, right now I have a setup like so:

flowchart TD
    A[Backend app] --> B[Common TypeScript library]
    C[Common AssemblyScript library for managing WASM memory] --> B
    D[AssemblyScript module] --> C
    E[Another AssemblyScript module] --> C

Loading

I'm using tsc to compile the common library while using AssemblyScript's types, then compiling the library into each module. From what I understand, I don't need portability in this case. The editor integration features seem to work a little oddly, but I'm assuming that's from my project structure as opposed to a difference with AssemblyScript, and the issues aren't major enough to be worth debugging anyways.