* Use analyzers from targeting pack for NetCoreAppCurrent
Fixes that analyzer failures didn't show-up in #74897
Add analyzers to the frameworklist that OOB projects in src/libraries
use, and only auto ProjectReference the analyzers in generators.targets
when not using the analyzers from the targeting pack.
Also move the generator projects related code into a separate file.
Continuation of https://github.com/dotnet/runtime/pull/75093
* Fix project build
* Add missing reference to Regex tests
* Add missing generators for netfx build
* Fix paht in test project
* Fix typo
* Disable runtime marshalling for SharedTypes.csproj
* Disable runtime marshalling for NativeExports.csproj
The function is looking for access information with a specified type at
a specified offset, but was using the wrong list here. That would in
some cases with overlapping accesses cause us to fail to find the
Access. The net result is that we rarely end up not promoting some
induced accesses that we would otherwise promote.
* add zero byte read to SslStream
* fix test
* Apply suggestions from code review
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* feedback
* add back missing line
---------
Co-authored-by: Stephen Toub <stoub@microsoft.com>
Fixes https://github.com/dotnet/runtime/issues/87585
When looking at the 8.0 Preview 5 SDK, xml files are missing for certain
assemblies. This is likely because of the TargetFramework condition in
intellisense.targets. Instead of conditioning on the rid-less net8.0
TFM, use the sfx.proj which already assemblies the shared framework and
targeting pack layout to copy the documentation files.
Additionally, remove the XmlDocDir and copy the files into the targeting
pack folder which was a difference between the "real" targeting pack and
the "fake" one that libraries generates.
.. when chrome fails to launch. For example:
```
Error Message:
System.IO.IOException : Process for /root/helix/work/correlation/chrome-linux/chrome unexpectedly exited with 127 during startup.
Stack Trace:
at DebuggerTests.WasmHostProvider.LaunchHostAsync(ProcessStartInfo psi, HttpContext context, Func`2 checkBrowserReady, String messagePrefix, Int32 hostReadyTimeoutMs, CancellationToken token) in /_/src/mono/wasm/debugger/DebuggerTestSuite/WasmHostProvider.cs:line 77
at DebuggerTests.ChromeProvider.StartBrowserAndProxyAsync(HttpContext context, String targetUrl, Int32 remoteDebuggingPort, String messagePrefix, ILoggerFactory loggerFactory, CancellationTokenSource cts, Int32 browserReadyTimeoutMs, String locale) in /_/src/mono/wasm/debugger/DebuggerTestSuite/ChromeProvider.cs:line 60
at DebuggerTests.TestHarnessStartup.<>c__DisplayClass13_0.<<Configure>b__2>d.MoveNext() in /_/src/mono/wasm/debugger/DebuggerTestSuite/TestHarnessStartup.cs:line 143
--- End of stack trace from previous location ---
at DebuggerTests.Inspector.OpenSessionAsync(Func`3 getInitCmds, String urlToInspect, TimeSpan span) in /_/src/mono/wasm/debugger/DebuggerTestSuite/Inspector.cs:line 414
at DebuggerTests.DebuggerTestBase.InitializeAsync() in /_/src/mono/wasm/debugger/DebuggerTestSuite/DebuggerTestBase.cs:line 173
```
For struct uses we need to take care to insert any necessary writeback
when we see the local in post-order. The existing approach waits until
it sees the GT_RETURN or GT_CALL node to create writebacks for the
operand, which can cause us to create a writeback that overlaps
improperly with a previous LCL_VAR. For example:
```
Processing use [000014] of V00.[002..004)
STMT00008 ( 0x023[E-] ... ??? )
[000025] --CXG------ ▌ CALL byref Program:M1(S0,short):byref
[000023] ----------- arg0 ├──▌ LCL_VAR struct<S0, 12> V00 loc0
[000021] --CXG------ arg1 └──▌ CAST int <- short <- int
[000020] --CXG------ └──▌ IND int
[000018] --CXG------ └──▌ CALL byref Program:M1(S0,short):byref
[000016] ----------- arg0 ├──▌ LCL_VAR struct<S0, 12> V00 loc0
[000017] ----------- arg1 └──▌ LCL_VAR int V01 loc1 (last use)
New statement:
STMT00008 ( 0x023[E-] ... ??? )
[000025] -ACXG------ ▌ CALL byref Program:M1(S0,short):byref
[000023] ----------- arg0 ├──▌ LCL_VAR struct<S0, 12> V00 loc0
[000021] -ACXG------ arg1 └──▌ CAST int <- short <- int
[000020] -ACXG------ └──▌ IND int
[000018] -ACXG------ └──▌ CALL byref Program:M1(S0,short):byref
[000089] -A--------- arg0 ├──▌ COMMA struct
[000088] UA--------- │ ├──▌ STORE_LCL_FLD ushort V00 loc0 [+0]
[000087] ----------- │ │ └──▌ LCL_VAR int V09 tmp6
[000016] ----------- │ └──▌ LCL_VAR struct<S0, 12> V00 loc0 (last use)
[000017] ----------- arg1 └──▌ LCL_VAR int V01 loc1 (last use)
```
The writeback `[000088]` should have been created before `[000023]`.
This change fixes the problem by moving the writeback logic into
ReplaceLocal. To properly handle commas we need to keep track of the
ancestor stack now.
Fix#87611
* We were sending the scriptId of a context that was already destroyed and vscode-js-debug extension started to consider this information that was ignored before.
* addressing @radical comments
Handle readbacks for parameters/OSR-locals like any other readback is
handled. Previously they were handled by creating the scratch BB and
then inserting IR after the main replacement had already been done; now,
we instead create the scratch BB eagerly and mark these as requiring a
read back at the beginning of the scratch BB, and leave normal
replacement logic up to handle it.
The main benefit is that this unification makes it easier to ensure that
future smarter handling of readbacks/writebacks (e.g. "resolution")
automatically kicks in for the common case of parameters.
Introduce another invariant, which is that we only ever mark a field as
requiring readback if it is live. Previously we would always mark them
as requiring read backs, but would then check liveness before inserting
the actual IR to do the read back. But we don't always have the liveness
information at the point where we insert IR for readbacks after #86706.
Also expand some debug logging, and address some feedback from #86706.
Forward sub was not taking into account that the source of the candidate
def can contain locals that may be changed by next statement that is
being forward substituted into. For example, it is not legal to forward
substitute V06 in the following case:
```
[000104] DA--G------ ▌ STORE_LCL_VAR short V06 tmp5
[000109] ----------- └──▌ LCL_VAR short V07 tmp6 (last use)
[000139] -A--------- ▌ COMMA void
[000121] DA--------- ├──▌ STORE_LCL_VAR int V07 tmp6
[000145] ----------- │ └──▌ CAST int <- short <- int
[000074] ----------- │ └──▌ CNS_INT int 1
[000129] UA--------- └──▌ STORE_LCL_FLD short V00 arg0 [+16]
[000143] ----------- └──▌ CAST int <- short <- int
[000090] ----------- └──▌ LCL_VAR int V06 tmp5 (last use)
```
Fix#87614
* Localized file check-in by OneLocBuild Task: Build definition ID 679: Build ID 2203090
* Localized file check-in by OneLocBuild Task: Build definition ID 679: Build ID 2203090
Fixes an `IndexOutOfRangeException` thrown by the analyzer when
analyzing method parameters for the implicitly generated Main
method when using top-level statements. These method parameters
don't have location info because they are not in user code.
This also adds checks in the other places this analyzer accesses
`Locations[0]`, to be safe.
* Do not quote rpath passed to linker
Looks like this is preserved literally, with the `'`.
The Android loader doesn't like this: `WARNING: linker: Warning: unable to normalize "'/data/data/com.termux/files/home'" (ignoring)`.
* Update Microsoft.NETCore.Native.Unix.targets
* Apply suggestions from code review
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
---------
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Places a limit on the number of values tracked in our dataflow analysis, to
prevent hangs in the illink analyzer. This avoids hangs when analyzing patterns
that currently lead to an exponential number of tracked values.
Fixes https://github.com/dotnet/runtime/issues/86462 by walking
debug info to discover typerefs in the assembly that are only
preserved due to debug info. In this case the assembly has the
'save' action, so the reference to the typeref in the debug info
is not swept. This means that the presence of the typeref in the
final output depends on whether we are linking the PDB. Walking
the typeref will preserve the assemblyref that it refers to,
fixing the issue.
The fix also needs to walk up the parent import scopes,
discovered by reproducing the issue in our test infra.
The behavior needs to depend on whether we are linking debug
symbols, otherwise we will keep the assemblyref (but not the
typeref that uses it) when PDBs are present, and the output
should not depend on the presence of
PDBs. `AssemblyOnlyUsedByUsingSaveAction` tests this case - see
comments in there for more detail.
This includes some unrelated test infra changes (supporting
multiple additional compiler arguments) which were useful for
iterating on this, even though they aren't necessary in the final
version of the testcases.
